Thanks for reporting - this appears to be happening because of cookie blocks rather than autoblocks. Following the steps locally, I find:

• the sysop is only blocked if cookie blocks are enabled ($wgCookieSetOnAutoblock = true)
• the sysop sees the same block message as the blocked user, rather than the autoblock message
• the block ID cookie is set

Note that to confirm this, you'll need to make sure the cookie is cleared first, e.g. by setting the config to false, unblocking the blocked user, and opening the editor as the newly-unblocked user. After that, following the steps in the task description, the sysop should not be blocked (and there should still be an autoblock for anonymous users).

Cookie blocks that spawn from user account blocks are intended to block other logged in users (T5233), and there is currently no 'cookieblock-exempt' right. Perhaps there should be - or perhaps the 'ipblock-exempt' right should protect from cookie blocks too?

It may be that this issue has only been noticed recently because the default config for cookie blocks have recently changed: T191922. I notice that in T191922#4122153 @Krinkle suggested leaving the default in DefaultSettings as false and overriding CommonSettings to true for all WMF wikis. Worth revisiting that idea since cookie blocks can be quite aggressive?

To summarize, this is not strictly speaking a bug, but it may be worth considering:

• should 'ipblock-exempt' exempt users from cookie blocks too (or should we have a 'cookieblock-exempt' right)?
• should $wgCookieSetOnAutoblock (and $wgCookieSetOnIpBlock) be false by default in core?

@dmaza - do you have any thoughts on changing the config back to false in core?

In T233441#5516930, @Tchanders wrote:

@dmaza - do you have any thoughts on changing the config back to false in core?

I believe my argument for that patch was that cookie blocking should be a standard feature and thus be enabled by default in core. We were already enabling it for all our wikis via CommonSettings.

should 'ipblock-exempt' exempt users from cookie blocks too

I think this make sense. Cookie blocks only represent ip targets and if you are ipblock-exempt you should not be affected by it(?).

I believe my argument for that patch was that cookie blocking should be a standard feature and thus be enabled by default in core.

Thanks, I saw your comment on the original task but thought it might be worth revisiting the decision given the confusion that arose here...

Cookie blocks only represent ip targets

Cookie blocks can arise from blocks against IPs or against user accounts. If a cookie block comes from a user account block, it will block logged-in users. That's what's happening to cause this issue.

You'll find yourself autoblocked and unable to take any action due to the removal of the unblock-self right.

This is not entirely true. Deleting the cookie will remove the block.

Change 570771 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/core@master] Exempt users with 'ipblock-exempt' right from cookie blocks

https://gerrit.wikimedia.org/r/570771

Change 570771 merged by jenkins-bot:
[mediawiki/core@master] Exempt users with 'ipblock-exempt' right from all cookie blocks

https://gerrit.wikimedia.org/r/570771

Autoblock cookie remains after logging in as admin, but not applied. Remains after logging out (so user is blocked again).

IP block is removed when you log in, so does not matter.

Version: https://en.wikipedia.beta.wmflabs.org MediaWiki 1.35.0-alpha (8035384) 09:23, 22 February 2020