The timing and also the root issue: Alan wants the `c-mode` symbol to mean "The mode I maintain, named 'CC-mode". The (dare I say) community is moving in the direction of it meaning "The mode users want to use for C (and C++ and C-like) files" (note: IIUC, this has outsized impact on the entire emacs ecosystem because a lot of modes for c-like languages are built atop the user's c-mode to save a lot of repetition, so the c-mode is both a major mode in its own right and the support framework for several other modes).
Ultimately, "name ownership" isn't really a thing, it's going to be a lot more convenient to change one symbol's semantic meaning than to require an unknown number of additional dependent projects to remap to some other symbol, and while I respect Mr. Mackenzie's frustration, one's "ownership" is always limited when one works on free software collaboratively with others.
These names are not internal names, like identifiers in the C source code of vim. The names in question appear in lot's of users Emacs configuration files. And Emacs has been extremely reluctant to change the meaning of those names in the past. Doing it here contradicts an important expectations of long time users. This is not only about "name ownership" of some mode's maintainer.
Unless I misunderstand, the idea is that treesitter C-mode is supposed to be pretty-much a replacement for traditional c-mode, right? As in "In circumstances where I want to invoke the C-major-mode, I now want to invoke the one that uses treesitter?"
If so, shifting the interpretation of the `c-mode` symbol seems the right avenue to accomplish that goal.
No, Emacs has lots and lots of config variables and functions which depend on the exact mode used. So, if you switch the major mode, you also have to switch to other config variables and functions. And as far as I see it, c-ts-mode is far from being a drop in replacement for everyone that currently uses c-mode.
Ultimately, "name ownership" isn't really a thing, it's going to be a lot more convenient to change one symbol's semantic meaning than to require an unknown number of additional dependent projects to remap to some other symbol, and while I respect Mr. Mackenzie's frustration, one's "ownership" is always limited when one works on free software collaboratively with others.