Calling AuthManager::autoCreateUser() with AuthManager::AUTOCREATE_SOURCE_MAINT would not work here as CentralAuth (and presumably similar central account management extensions) will reject the account creation if the global account, or the local account on other wikis, is already reserved. So there needs to be a way to steal a central account and to merge/attach local system users accounts on various wikis.

Maybe User::newSystemUser() could call LocalUserCreated with a flag denoting that it's a system user (and possibly the create/steal flags), and extensions like CentralAuth can act on that by stealing or attaching the global account (and presumably implement a global version of T212720: System users should be in a dedicated user group so they can determine when that's safe)?

In T214722#4910027, @Tgr wrote:

So there needs to be a way to steal a central account

The central account does get stolen if a local non-system user exists for the name: in that case CentralAuthPrimaryAuthenticationProvider->testUserCanAuthenticate() returns true (and probably the user has a valid email or token too), so User::newSystemUser() will call AuthManager->revokeAccessForUser() and SessionManager->preventSessionsForUser(), both of which will cause CentralAuth to blank the password for the user.

If no local account exists for the name, it'll just create a new unattached local account without messing with the central account. If an unattached local account exists, then CentralAuth similarly shouldn't be messing with it but it looks like CentralAuthSessionProvider::preventSessionsForUser() is missing an ->isAttached() check so it will.

See also {T53837}.

"Stolen" in the sense that the owner is locked out, yes, but the system account will not get attached to it. It would make system users less confusing for editors if they had a proper central account, with a central user page and everything, with the local system user accounts attached to it.

Not Miraheze specfic

Flow does this manually (in TalkpageManager::getTalkpageManager()) by creating a system user and then calling CentralAuthUser::attach( <wiki id>, 'admin' ).

I propose that we can introduce a new user name format for system user names. For example the abuse filter blocker can be named User:@abusefilter-blocker in every wiki, and a localized named (stored in a MediaWiki message) can be shown in page history, recent changes and logs.

Since @ is not a valid character in new user name there are little risk of conflicts with existing users. There are no conflict with interwiki user name either (which always have a (.+)@([^@]+) format). Such accounts can safely be connected to SUL automatically.