this take is dumb, perhaps because you're not familiar with emacs? it's a lisp machine where everything gets loaded in and stumbles around in one big global namespace, social coordination, not technical controls, is used to stop them messing with each other, and in this case it didn't happen.
the patch being complained about more or less unilaterally deprecated the extremely well-established C and C++ modes written by the email's author.
Namespaces won't solve the problem. If you have namespaces/packages you can have foo:c-mode and bar:c-mode.
But if you're always using the qualified names, they are not better than just prefixes like foo-c-mode and bar-c-mode. The point of packages is that you can set up a context where you can just use c-mode, which is one of those two: either foo:c-mode or bar:c-mode. Somehow that selection has to be made, and there it's possible to continue to have arguments and drama: which one should be the default one in a vanilla installation? Or do we barrage the user with a flurry of questions to resolve each such a conflict?
When the installation is complete, and the user opens a .c or .cc file, it has to be handled by a mode which is chosen somehow from among the alternatives.
Maybe how it should work is that the first time the user opens a .c file (or other related suffix) they get prompted for which mode they would like to handle it with. The choice is then remembered, but with the option not to remember ("just this once"). Gee, either I've seen that before or I'm a UX visionary.
the patch being complained about more or less unilaterally deprecated the extremely well-established C and C++ modes written by the email's author.