I don't see how focusing the available manpower on one implementation instead of splitting it over 10 different implementations would make this worse.
I do see how it would make this much better.
What one implementation lacks, another implementation provides. This is a weakness of the current ecosystem. Most software projects restrict themselves to the minimum common denominator, and splitting manpower across compilers lowers it.
You sound like you haven't worked with many BigCo projects. Clang is turning into an "enterprise" junkyard due to too many cooks spoiling the broth, crumbling so much under the weight of its own complexity that 2022 is almost here and support for C++20 still isn't anywhere near complete (unlike GCC). The more parties that get involved, the worse the code will get. Clang already has more people working on it than MSVC, yet MSVC is iterating faster; this suggests a fundamental problem with the architecture or development processes of Clang, which is not something that will be fixed by more hands on deck (remember the mythical man-month).
I don't see how focusing the available manpower on one implementation instead of splitting it over 10 different implementations would make this worse.
I do see how it would make this much better.
What one implementation lacks, another implementation provides. This is a weakness of the current ecosystem. Most software projects restrict themselves to the minimum common denominator, and splitting manpower across compilers lowers it.