I appreciate the sentiment, but I think there's a problem with your proposed methodology (which I readily admit I do not have a direct solution to).

Requiring so much proof puts a significant burden on people who might actually be in the affected group.

(Before going further, I want to say that I am not in this comment taking a firm stand on the master->main transition directly, but rather commenting on this type of process in general.)

Let us assume that in the general population GP of people exposed to a given term T, there exists some portion of people who feel they are negatively affected by it (GP_n) and those who do not feel directly affected by it at all (GP_0).

A proposal is made to transition from using T to T'.

Some portion of GP_0 will report that they are opposed to this transition, which we can call GP_opp. I would argue that, based on reactions to the master->main issue, the members of GP_opp are either a significant portion of GP_0, or else are incredibly vocal.

Members of GP_opp call on GP_n to make their voices heard and to systematically prove their injury due to use of T. They say "I do not see the problem with T. Please explain to me why you find use of T bad, and why T' is a better substitute."

Many members of GP_opp make this call.

So now those in GP_n — which was likely a minority of GP to begin with — find themselves needing to explain over and over again the same issue. It is tiring, and it is burdensome. They are constantly needing to defend their emotions against people who claim that the T->T' transition is illogical and baseless.

I would argue that this is an undue burden. We, as a society, should do better. If the T->T' transition is not incredibly difficult to perform, and if T' is a strictly (or even just mostly) improved alternative to T, then I think we should not be requiring members of GP_opp to defend themselves systematically. We should not be going to great lengths to prove the necessity of the transition, because the transition itself is not that big of a deal. It's a relatively minor change, but one which when completed leaves us in a net positive state.

There's no particularly good reason not to make the T->T' transition, other than "tradition" or a minuscule amount of effort.

---

Applying engineering principles to human problems only serves to maintain a status quo that we already know is harmful to people in various minority groups (whether race or otherwise). Yes, it sounds reasonable, but that's really the issue with a lot of things going on lately to begin with: it sounds reasonable, but it really isn't, because arguing in favor of it requires ignoring the emotions of the people who are most likely to be affected to begin with.

I think instead we, as a society, should be moving towards arguing on behalf of people who might be injured, instead of requiring the injured to defend themselves. If no harm is done by transitioning from T->T', then why fight it? What good reason is there to not be onboard with such a change?

I cannot think of one, so I err on the side of trying to consider the feelings of those who I haven't met. I try to think about how what I do may affect others, instead of requiring that other people prove that I have affected them.

---

It's definitely worth putting some consideration into these things to ensure we're not wasting time on a bunch of unimportant stuff, but when it's something as trivial as changing the name of default branches of git repositories... I don't see what the hullaballoo is all about. Why shouldn't we? What are we avoiding? It seems to me that there's just a lot of people who are uncomfortable with change in general, and unfortunately it is this attitude that has by and large caused social progress of important issues to stagnate. Too many people fight change for the sake of fighting change, and the end result is we don't improve as a society. Maybe taking small steps like this more often will help us with making the big steps more often too, and I think that's a more important consideration overall.

Just my (wordy) $0.02.