Definitively agree on the hold feature request.

Totally agree; though perhaps a different note section should be added which the requester won't be able to see?

What workflow changes would the "hold" feature add? Are you just looking for a way to mark a request as under discussion in some way so that multiple renamers don't try to take action on it?

Pretty much the case that there would be no need to change the workflow. I think that the hold just needs to be a symbolic barrier to processing rather than a locking feature. Notes can capture where the discussion is taking place.

Any update on this one? What is needed here?

It's not assigned to anybody.

@Aklapper Is it possible to increase the priority ? This request has been discussed several times at the global renamers mailing list

In T94321#3349007, @Framawiki wrote:

@Aklapper Is it possible to increase the priority ? This request has been discussed several times at the global renamers mailing list

@Framawiki: Do you plan to work on fixing this, or do you know somebody who plans to work on this task?

In T94321#1894094, @Trijnstel wrote:

Any update on this one? What is needed here?

The implementation would be patches to the CentralAuth extension.

• The enum of valid values for the renameuser_status.ru_status database column would need to be patched to add an 'onhold' status value.
• A new class constant would be added to includes/GlobalRename/GlobalRenameRequest.php
• includes/specials/SpecialGlobalRenameQueue.php would need updates to implement management of the new state
  • this would probably involve copying the way that the open/closed lists are handled to add a new 'on hold' list
  • the SpecialGlobalRenameQueue::doShowProcessForm and SpecialGlobalRenameQueue::onProcessSubmit would need updating to add a way to set the new status
• includes/specials/SpecialGlobalRenameRequest.php would need to be updated to display the new status to the requesting user

There are probably some messages and related changes that I'm not thinking of right now, but that would be the basics. The database schema update needed for production would need to be approved by the Foundation DBA team, but I don't see any obvious issues with it. The table being changed is neither large nor frequently queried.

Then the changes need to be reviewed, the database updates made in beta cluster & prod, the patch merged, and eventually the feature would be deployed on the normal MediaWiki deploy cadence. The patches needed could probably be prepared by someone with moderate MediaWiki/PHP development experience. It would mostly be extending existing code and user interface design.