We could probably take most of the code from GlobalRename in CentralAuth and make it not-dependent upon CA. I think you'd still want to have a global renameuser_status table and use the job queue.

Just taking a quick look at the LocalRenameUserJob class (which is where most of the work is done), it's mostly not CA-specific, except for the promotetoglobal option which isn't needed, and CA cache invalidation, which also won't be needed.

It may make sense to wait for T100263: Refactor Special:RenameUser to use FormSpecialPage to be finished first, as it'll be easier to do once the backend is separated from the frontend.

Closed https://github.com/Brickimedia/brickimedia/issues/168 as that ticket was superseded by this ticket.

Just adding my two cents here that as an external wiki farm, we'd also like to see user renaming support wiki farms properly, especially now that it is integrated into core. We use a fork of the Renameuser extension, but to upgrade to 1.40, it means that we're likely going to have to make patches to the core implementation instead.

Our fork code (which isn't exactly gold standard, but works) involves looping through $wgLocalDatabases and inserting a job for each. The job then updates tables on each wiki before finally moving the user page on each wiki.