I got involved with scheme back in the days of R{5,6}RS (as a user, not in the standards process). Even then it was an argument for the BDFL model over design by committee.
Committee consensus took us up through R5RS. There were about 30 members of the committee, though obviously some were more active than others. The problem with that was that we got no change except at the margins. Implementations were extended in random incompatible ways.
Then we had consensus of a small committee (5 members, later 4) for R6RS, followed by a community ratification vote. A lot of people thought the resulting standard was over-engineered, and I am quite sure that many people didn't understand all of it (I didn't for sure, especially macros and records.) Some implementers adopted it, others declared they never would.
For R7RS-small and the early stages of R7RS-large, we had the open SRFI process (anyone can propose, the community helps refine, the author decides when to freeze the result).
Now we have a (de facto) Sitzfleisch process: however stays in their seat and is still arguing the longest, wins. I eventually ran out of energy for this one.
Note that in all cases the text controls the meaning, not the author(s), and when the standard and an implementation collide, it is the implementation that is wrong. This is very nearly a sacred principle, as in C/C++ and various other multiple-implementation languages.
I wonder if the optimum is a benevolent dictator controlling the language and committee controlling the associated library. The community is then a sort of third ring of library evolution.
Inconsistency is more expensive the closer to the language definition it arises as the blast radius is wider.
Compromises and redundancy are more valuable in the library layer.
Lisp blurs the lines somewhat but it's usually possible to subdivide a system into a core and stuff built on that core.
As someone who works on a combined language/core library team, it's really nice to have them both under the same roof. We can provide a much better overall user experience when we can design features that involve the language and core libraries working in concert with each other.
For example, we recently added tuples as a language feature to Dart, and also added a function in the async library that lets you await a tuple of futures in parallel and returns a future of the tuple of the resulting values.
When we added extension methods to the language, we also rolled out some extension methods in the core library.
Committee consensus took us up through R5RS. There were about 30 members of the committee, though obviously some were more active than others. The problem with that was that we got no change except at the margins. Implementations were extended in random incompatible ways.
Then we had consensus of a small committee (5 members, later 4) for R6RS, followed by a community ratification vote. A lot of people thought the resulting standard was over-engineered, and I am quite sure that many people didn't understand all of it (I didn't for sure, especially macros and records.) Some implementers adopted it, others declared they never would.
For R7RS-small and the early stages of R7RS-large, we had the open SRFI process (anyone can propose, the community helps refine, the author decides when to freeze the result).
Now we have a (de facto) Sitzfleisch process: however stays in their seat and is still arguing the longest, wins. I eventually ran out of energy for this one.
Note that in all cases the text controls the meaning, not the author(s), and when the standard and an implementation collide, it is the implementation that is wrong. This is very nearly a sacred principle, as in C/C++ and various other multiple-implementation languages.