This is what killed all the momentum that Elm had at one point. While that's a language and not an entire editor, it does serve as an illustrative example of being far too strict about accepting changes to core.
For projects without funding, there is typically a trade off between a polished coherent product, which means saying no a lot, and a bloated product that has enough maintainer bandwidth to stay around. The second means saying yes to things which may not make the product better, in order for newcomers to feel bought into the project and want to maintain it.
For something like an editor, where whole features can be turned off by default, there's quite a bit of leeway to add bloat and get newcomers to buy in, without actually making the product worse.
For a programming language, a feature in the language has to be used by everyone. So the leadership has to say no a lot to keep the language high quality, and that makes it hard to get newcomers to buy in.
Unfortunately you can't have it both ways without paying people to maintain the project. Elm was good because the leadership said no...often.
It's dead because the leadership said no so often that no one wanted to help maintain it. No one is going to waste their free time working on a project that won't accept their ideas, nor should they.
A language like Go doesn't have this trade off. If the Go leadership rejects a google employee's proposed language change, the employee still has to do maintenance chores as directed to keep their job.
For projects without funding, there is typically a trade off between a polished coherent product, which means saying no a lot, and a bloated product that has enough maintainer bandwidth to stay around. The second means saying yes to things which may not make the product better, in order for newcomers to feel bought into the project and want to maintain it.
For something like an editor, where whole features can be turned off by default, there's quite a bit of leeway to add bloat and get newcomers to buy in, without actually making the product worse.
For a programming language, a feature in the language has to be used by everyone. So the leadership has to say no a lot to keep the language high quality, and that makes it hard to get newcomers to buy in.
Unfortunately you can't have it both ways without paying people to maintain the project. Elm was good because the leadership said no...often. It's dead because the leadership said no so often that no one wanted to help maintain it. No one is going to waste their free time working on a project that won't accept their ideas, nor should they.
A language like Go doesn't have this trade off. If the Go leadership rejects a google employee's proposed language change, the employee still has to do maintenance chores as directed to keep their job.