It sounds like a classic case of the Second System effect. Where the original product was functional but a maybe little too basic, so everybody has an idea of how to improve it. Many of the ideas are good on their own, but the committee ends up accepting far too many and the thing suffers from terminal feature creep.
Perhaps we should make a language with a hard cap on the number of “features” in the language syntax + standard library. For everything you propose to add, you would then also need to propose something to remove.
> For everything you propose to add, you would then also need to propose something to remove.
There are surely lots of features the proposer would be willing to remove (although one also has to define how to count the number of features, or else every proposal, no matter how long, will be for one giant feature, and will propose removing one tiny feature in return). The problem is that what I consider dispensable in return for my essential proposal will conflict with what the next programmer over considers essential ….
Though in principal I love the idea, it would kill backwards compatibility. But maybe each major version revision should have a vote on keeping or removing some older features.
Only those holding no stakes would play the vote game; anyone actually depending on compatibility would silently (or sometimes not so silently) depart.
