User::getBlockedStatus has some ugly checks to see whether the User object whose status has been queried is the same as the global user (to determine whether the IP from $wgRequest can be used to check for IP blocks).

Looks like that check was first added in rSVN56325, fixing a similar bug where it was using the request's IP when checking blocks for all User objects rather than only the session user. No indication as to whether they compared user names (versus mFrom === 'session' or the like) there for a specific reason or just because that seemed like the safest way to not maybe break something else.

User::getRights() has been refactored into PermissionManager::getUserPermissions() which has a comment saying FIXME: $user->getRequest().. need to be replaced with something else. So presumably in the long term a different mechanism will be needed to signal whether the permission check should take session restrictions into account. Possibly T212639: Separate could do / can do / is doing permission checks in MediaWiki.

I agree that building that distinction into the new PermissionManager's interface would be beneficial.

Note that PermissionManager now has an internal cache so it's impossible for User objects representing the same User to have different rights, e.g. in case one is a session user and the other is used in some different context. (See T227772#5340242.) Although there's probably no real use case for that anyway.

Err, this task is the real use case for that. But as mentioned the use case here could be satisfied by more explicit requests for "rights for the user in this session" versus "rights for this user generically".

Fixing this has become possible with the introduction of the Authority interface. It should actually be fixed automatically as part of T271463: Refactor PermissionManager into Authority [hard].