Exactly because of much greater stakes. A lot of heavyweights involved, and nobody agrees to yield. The result is a compromise, aka a solution which is unsatisfactory to all parties to an equal degree, as they say.

Best designs are produced by small, tightly-knot, often one-person design teams. Examples: Unix, Clojure, SQLite, Boeing-747, Westminster Palace in London.

Sometimes a small team with a cohesive vision keeps on attracting like-minded people or matching ideas, and the project grows with contributions from a large number of people. The key part of every such success is the vetting process. Examples: Python, Ruby, FreeBSD and OpenBSD.

Worst designs with most glaring, painful, expensive, even tragic shortcomings are produced by large committees of very important people from huge, very (self-)important companies, agencies, departments, etc. Each of them has an axe to grind or, worse, a pet peeve. Examples: PL/I, Algol-68, the Space Shuttle (killed two crews because the escape system was removed from the quite sane initial design); to a lesser degree, it's also HTML, CSS, and, well, C++ to a large degree :( The disease has a name [1].

Sometimes a relatively small and cohesive team in a large honking corporation produces a nice, cohesive design, like this happened to Typescript, certain better parts of CSS, and some of the better parts of C++. This may sometimes make a false impression that "design by committee" sometimes works.

[1]: https://en.wikipedia.org/wiki/Design_by_committee

Because the C family is guided by a committee. Even worse, an important and respected committee.

After a decade of using obj-c modules I'm still unclear on what the benefit of them is other than the Swift bridging aspects of it. There isn't really any observable difference in either compile-time performance or behavior from turning them on and off other than that a lot of the rules around inclusions are much stricter with modules enabled. The documentation claims that they should improve build performance, but AFAICT that isn't actually true or the difference is so small as to be irrelevant.

Is easy, you don't have the same amount of courdination problem, most of what's wrong in software today have in big part problems whit two things legacy and coordination problems, need back compatibility means that useful solution aren't posible, soy then you need to compromise and then compromise again because some users cant use you solution, so now you have solution who don't satisfied anyone, sum that whit natural misalignment of any organization and is obviously that focus sitmrs whit few stakeholders and willingness and capacity to break change can do a better job, this ins't particular problem of programming.

Backward compatibility with existing compilers.

And more importantly, not breaking old, old codebases, which is a very critical problem.

Obj-C++ and D don't have critical codebases, because there is just so much less code. Apple does what they want.

Like Stroustrup says, when a language is not used, it won't generate problem: I gues his quote is often quite overlooked, but it's very very true.

Compilers are a difficult topic.