This (the "another use case") is superprotect all over again.

I don't see how. Locking is always available for a "superprotect". Stopping users from appealing anywhere but meta seems much preferable to locking.

In T355385#10094212, @Pppery wrote:

This (the "another use case") is superprotect all over again.

See parent task - it will replace current usages of locks for e.g. WMF banned users, since CentralAuth will no longer have a lock feature.

Currently local wikis already can not opt out global locks.

I will suggest a highly-restrictive of usage of such instead. See https://meta.wikimedia.org/wiki/Requests_for_comment/Global_account_blocking_practices#c-GZWDer-20240826114100-Discussion

In T355385#10094212, @Pppery wrote:

This (the "another use case") is superprotect all over again.

I would argue that this isn't the case, primarily from the point of view that this would be an option present for the stewards to use (and not the WMF) in all but a rare case. The WMF would only use it in the case of WMF global bans, which are rare. Plus the WMF can already do this through a global lock (which is why this task needs to be done to merge locking into global blocking).

Change #1281877 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/GlobalBlocking@master] Remove use of whitelist in comments and variable names

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