Renaming the "master" branch without breaking existing clones

[Apologies if there is an existing thread about this; I searched hard and wasn't able to find one.]

I've just become aware of the discussion that the name of the "master" branch should be changed. I'm not taking a position on this now, but it seems enough people want to make the change that we should resolve the technical problems, of which I see several:

1. Allowing tools to be configured to change the default name for new
repositories.  Work on this appears to be well underway with no
fundamental obstacles.

2. Renaming the branch in existing repositories.  I've seen a number of
guides for how to do it in the central repository, and they all seem to
expect users with existing clones to manually reconfigure them all at
once.  To me, that amount of disruption would be unacceptable for
central repositories I'm in charge of (admittedly few with few users,
so I imagine some will argue I should leave it to the bigger players to
complain about this), whether or not one believes that the social
justice benefit of changing the branch name in personal clones merits
the work at all.  I found only one guide that addresses this problem:

https://github.com/chancancode/branch-rename#gradual-migration

It includes a procedure to mirror the "master" branch from the new default branch so that readers of the central repository don't need to reconfigure anything. Writers need to be reconfigured. That seems reasonable to me.

Unfortunately, the mirroring method seems to be specific to the repository hosting service being used. If services supported standard git hooks, that would probably work, but I can understand if the services don't because it's unwieldy to execute shell scripts without introducing security risks.

This guide seems well thought out to me on a first read, but I suspect there may be aspects that could benefit from a lot more scrutiny from experts, and I want to encourage them to provide it.

3. Ensuring that tools detect the default branch of a given repository
in an appropriate way rather than assuming "master".  Where applicable,
the remote HEAD symref is probably the best thing to use.  See for
example:

https://github.com/chancancode/branch-rename#packages-considerations

This category would also include git's feature of leaving the target branch name out of the merge message, for example. I believe the necessary work on git itself is underway; other tools may lag.

For read-only tools, this mainly matters for central repositories that eventually delete their "master" branch, which may not be all of them, but again, it sounds like there will be enough such repositories that we should consider the problem. I don't see any fundamental obstacle, but this may benefit from more scrutiny as well.

I'm aware that asking others to do work is often poorly received. This message is just to get people's attention so they can do the work if they wish.

Thanks for reading.

Matt