There are three different kinds of permission checks in MediaWiki:
* "could do": the user has at least a chance of being able to do this some of the time. This is mainly used for generating the UI (such as showing an edit tab or showing block links after usernames).
* "can do": the user wants to do this now. Typically checked before displaying the form where the user can perform the action.
* "is doing": the user has attempted to perform the action. This is similar to "can do" but can trigger side effects which should only be triggered once per action, such as logging or rate limiting.
Some of the issues that stem from our current perission system not having this split:
* "could do" checks just need a success/failure response, "can do" checks generally need an error message. Currently it is ad hoc which permission check methods can return one ({T180888}).
* We want to limit certain actions to an "elevated security" mode that the user enters by doing some login-style action ({T197136}). We want to incorporate this in the "can do" checks (don't let the user fill the form if the data will get thrown away on submission) but not in "could do" checks (we want to show the action links so we can send the user to the reauthentication process through them).
* Similarly, session restrictions should probably not affect "could do" checks (see {T218674}).
* More accurate auditing of attempts at performing sensitive actions, as opposed to logging a delete permission check just because the system wanted to know whether it should show a delete action tab
* Rate limiting inside the permission system (it has to live on the edges currently for the reason above)
* Handling blocks inside the permission system (T212311)
* Same goes for page restrictions probably