But https://meta.wikimedia.org/w/index.php?title=Special%3ALog&type=gblrename&oldname=User%3AS+Page+%28WMF%29 happened
So why hasn't the global rights entry updated?
So I think this is actually a larger question with global renames. We had the same issue with a globally locked account being renamed. The lock itself was transferred from Account A to Account A (Usurped) but the log entry did not.
https://meta.wikimedia.org/w/index.php?title=Special:CentralAuth&target=Commons%20fair%20use%20upload%20bot original account name with lock log (now owned by someone else)
https://meta.wikimedia.org/w/index.php?title=Special%3ACentralAuth&target=Commons+fair+use+upload+bot+%28usurped%29 usurped account with the lock correctly transferred but no log entry.
This is an issue with local renames itself.
When doing a rename:
UPDATE `logging` SET log_title = 'NewUser' WHERE log_type IN ('block','newusers','rights','renameuser') AND log_namespace = '2' AND log_title = 'OldUser'
and those log_types are from SpecialLog::getLogTypesOnUser() which doesn't know about CentralAuth's logs. It does have GetLogTypesOnUser hook but the problem is CentralAuth's logs are too weird. In gblrights, all changes to global groups and wikisets are also logged in addition to global user rights changes. In globalauth log also we've those @global stuff. I guess we can't use that hook here.
We don't want people to be able to globally rename from every wiki.
That is somehow a strange interpretation what is a global group, to see a "unconfirmed" user in local logs doing this. This group has only global change rights. Than a proper name would be:
Hidden global group
Adding User-RhinosF1 project and moving on that workboard to Miraheze Linked, as we're quite curious when this bug will be fixed. All local log entries have the performers and targets updated following a global rename, so why not global log entries, such as the global rights log?
Adding @Reception123 per request on IRC.