If people think this is useful then it's their time to spend on it; it's not our choice to make. If you don't like it then you can just ignore it. I really don't see the problem.
It's not our choice, but we can debate the choice. I think it's a bad choice, for many reasons, one of which is that having multiple competing forks that are all Rust but not quite isn't going to help Rust adoption and is going to cause fence sitters to look somewhere else. Whenever this kind of drama hits a language eco-system it is bad for the language, there is plenty of precedent.
I suppose so, but I don't think the effects will be all that large. And we can just as much blame the Rust Foundation people for putting out a trademark policy that's completely bonkers and more strict than almost any trademark policy (including those from Oracle, Microsoft, etc.) If you don't want people to take radical actions then don't do radical things.
Besides, a number of forks have had a positive effect on the original project: Emacs, GCC, GNU libc, Vim, probably more.
I don't think they really did much for their parent project though? They're just forks that are more successful than the parent, but that's a different thing. My point was mostly that forking doesn't need to be a zero-sum game and that everyone can benefit from it.
GCC had a standard to live up to (and it extended that standard in plenty of ways), the others aren't languages per se and do not and never did have the mission to appeal to the people that write non-sexy system software for a living. They value stability and a lack of drama in the suppliers of their tools above all else because any kind of fragmentation has the potential to cause them to have to (much) more work and they usually already have plenty of that.
And if the community was confident in Rust's leadership, this wouldn't be happening.
Which, to me, makes it seem that "hey, don't fork the community" is kinda brutally missing the point at hand, or at least feels aimed in the wrong direction.