We have the DisableAccount extension for this purpose, which according to https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php is enabled on both stewardwiki and CUwiki.

Is that not sufficient?

Presumably not. That is tool that we use and seemingly this report is that they still receive notifications.

Deactivate an account (variation of Special:Block)

... deactivated MarcoAurelio (Talk | contribs) with an expiry time of infinite (account creation disabled) ...

(In reply to billinghurst from comment #2)

Presumably not. That is tool that we use and seemingly this report is that
they still receive notifications.

Deactivate an account (variation of Special:Block)

... deactivated MarcoAurelio (Talk | contribs) with an expiry time of
infinite (account creation disabled) ...

Nope. That is the normal 'block' option (the block log messages are customized over there).

Deactivation mentioned by Legoktm above is what is done via Special:DissableAccount. However it (is/was?) policy of that wiki not to use that powerful blocking tool unless it was strictly necessary (compromised accounts, etc.) as suggested by WMF because its use was not logged anywhere (cf. bug 32782 - not sure if that's really logged now, there was an ad hoc page created there for that purpose) and because its use is only reversible with system administrator intervention.

It is not rare that some CUs (and happened with stewards as well, tho less frequently) wants to take a break, drops the tools and it's access is removed, and after a couple of months the user regains the tools tho is allowed to have access to the Wiki again. It'd be overkill IMHO to call a sysadmin each time an account needs to be reactivated, when a simple "unblock" can be done.

Rename is an option, to free again the name and create a new account under the old name; however his/her former edits will be attributed to their old account, which is not an optimal situation IMHO.

Best regards.

What if this task is being done and accounts need to be unblocked? Will the email then automatically be confirmed again? (ie. think about returning OTRS agents, CheckUsers and/or stewards)

In T54453#1027792, @Trijnstel wrote:

What if this task is being done and accounts need to be unblocked? Will the email then automatically be confirmed again? (ie. think about returning OTRS agents, CheckUsers and/or stewards)

I don't think thats the right way that emailconfirmed should be revoked (as only the merged task title suggests) if the goal is, that the account don't get watchlist notifications. Instead I imagine, when generating the mails, it should be checked if wgBlockDisablesLogin && user is blocked, and not send it.
However user talkpage notifications could be still allowed.

Reconfirming the email when one is back doesn't look like a huge burden.

However user talkpage notifications could be still allowed.

What for, if they can't access their talk pages? Also, the user wouldn't be able to disable such emails because preferences would be inaccessible. I agree it's possible to break down tthe disabling in many conditions, but unconfirming the email address is a reasonable first implementation.

Aye, user talkpage notifications are unhelpful to the user who can't log in to their account and on private wikis (like this is meant for) this are a security issue too since the notification can have snippets of what is posted. [obviously there is not generally a reason to post private information to a blocked wikis talk page but I can imagine a situation where someone hadn't noticed they were gone already or something like that]

In T54453#1028658, @Jalexander wrote:

Aye, user talkpage notifications are unhelpful to the user who can't log in to their account and on private wikis (like this is meant for) this are a security issue too since the notification can have snippets of what is posted. [obviously there is not generally a reason to post private information to a blocked wikis talk page but I can imagine a situation where someone hadn't noticed they were gone already or something like that]

True, I got with the user's talkpage thing on a wrong way for this situation. They can't see them when they are not logged in....

Can this be resolved using ways like T87559: Locked accounts should have mail-based notifications <s>receipt</s> disabled?

Change 194525 had a related patch set uploaded (by Alex Monk):
Prevent user from receiving email while blocked with $wgBlockDisablesLogin on

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

Change 194525 abandoned by Alex Monk:
Prevent user from receiving email while blocked with $wgBlockDisablesLogin on

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

Change 218602 had a related patch set uploaded (by Glaisher):
Don't send email notifs to blocked users if $wgBlockDisablesLogin is true

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

Change 218602 merged by jenkins-bot:
Don't send email notifs to blocked users if $wgBlockDisablesLogin is true

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