Also encountered this on enwiki. As described.

must?
Where the author is populated with a username link it's not impossible to have it updated. Certainly more onerous on the system, but not impossible.

An indication that uploads at Commons are not adjusted perfectly. The different treatment of Contributors (altered) and Authors (not altered) is a frequent gotcha for people trying to lose an association with their previous name.
https://commons.wikimedia.org/wiki/File:AliceAyres.jpg ties me to a username from 9 years ago.

I've emailed Legal for confirmation that the refusal was reported to them. They have not yet responded. The issue resolved once the loop is closed, not before. "All good at our end" isn't the required end-point.

Test case just came through from Läägpõrkur.

AFAIK this started life as a replacement for the requests which came through legal. An automated option to "delete" accounts was required by Google (& Apple ?). I assume it's there so Legal can account for the decisions when Google (& Apple ?} follow up on complaints.

Have the reasons for rejecting the rename been sent to the user? Or were they discarded?

In T328745#8587020, @Ammarpad wrote:

In T328745#8586316, @Cabayi wrote:

Thanks Ammarpad. That sorted it.
It worked once we also created https://arbcom-en.wikipedia.org/wiki/MediaWiki:Editnotice-0

I hope you understand that's a namespace-level notice, so it will appear on all pages in namespace 0. (Task description shows you probably want it for https://arbcom-en.wikipedia.org/wiki/Appeals/2023 only)

Thanks Ammarpad. That sorted it.
It worked once we also created https://arbcom-en.wikipedia.org/wiki/MediaWiki:Editnotice-0

"as it would be" - for the page Appeals/2023 I created Template:Editnotices/Page/Appeals/2023
Which of the "arbitration wikis" - https://arbcom-en.wikipedia.org

The big plus to Vector 2022 was regaining the ~15% of screen widthe taken up by the left-hand menu for displaying real content. If it now means losing ~30% to the ToC, with no way to turn it off, I'm switching back to the legacy Vector.

The gadget was altered several days ago. See Wikipedia:Dark_mode_(gadget). I needed to add
window.wpDarkModeAutoToggle = true;
to my common.js. I found its behaviour was a bit erratic for the first day or so after the change.

Also needed....

• Check if the requesting user is blocked (esp. hardblocked) on any WMF project & pre-populate a decline message if so.
• Default tick the suppress redirects checkbox
• Delete all their userspace pages except their top level user talk page, on all WMF projects (this is currently beyond the privilege set of stewards & renamers, it ought to be built in to the renaming tool)

I've just responded to a rename request arising from this.
It doesn't appear that any explanation was given to the user affected, just an edit summary left at the site of his former username.
This is poor handling of the users affected.

In T273003#6780172, @Dreamy_Jazz wrote:

cyberbot I has been blocked because of the blanking issues on enwiki

I blocked the bot because it didn't respond to the enable/disable switch on the task which had the blanking issues on enwiki, not for the blanking itself.

Cascading pblocks to subpages would also be useful for preventing hat-collecting edits to all the Wikipedia:Requests for permissions pages with just 1 pblock rather than blocking each request page individually, which achieves only a partial restriction and uses all the available pblocks on one task.

A more tightly grouped set of dates in the table shows that blanks are interpreted as 1970-01-01.