It screams of needing some sort of governance and RFC process ( edit: seems that there is an RFC process [1]) so that all parties could make their case.
The Angular 1 -> 2 transition should be a lesson to most that if you leave your users hanging, they'll go find another ecosystem.
In a perfect world (according to me), Elm would have 5-10 people in its core team, with at least a few of those tasked with triaging issues and PRs. That wouldn't mean "giving up" control of the language and its future.
That would be amazing, but I see this being very similar to Node in its infancy. It took a fork (io.js), and a lot of strong opinions to get Joyent to relinquish its grip on the ecosystem.
I think what the developers who forked Node into io.js showed was competency and care with regards to progress. I'm not sure that could ever happen in the elm ecosystem due to it being somewhat small and niche.
It seems to me that the extreme BDFL governance of Elm is also its strong point at the expense of being then limited to that bandwidth, it's weak point.
Unfortunately, delegating work does not come for free and a great deal of energy will be burned in people management. Unless you're clairvoyant, it can't be said whether that would be any better for Elm or mire it in an even thicker mud.
Elm has a lot of unknowns that someone has to sit down and make decisions about because it wants to generalize over environments beyond browser-side Javascript. I think that sits at the root of why you can't just delegate out core contributor access.
But trying to do that generalization in the first place is also why Elm has some really interesting potential in the long run than just another SPA abstraction.
There's also big examples like Perl 6 and Python 3.
IMO, you can make breaking changes as long as it's done gradually and you provide a clear migration path. After experiencing React's strategy [0] for a few years, I'd say it's become my gold standard for how breaking changes should be made.
[0] https://reactjs.org/docs/design-principles.html#stability