I wonder if there's something about changing uses cases. If you design for x and y use cases then you end up with a nice, simple design for x and y. People then start doing a lot of z so you adapt to support z, but it adds some complexity because it's not exactly what you had in mind when you laid the foundations.
A competitor comes along who's designed for y + z, and everyone loves how nice and simple it is. Then use case u comes along...
If we are to trust a certain philosophy based on simplicity, one of the _very hard_ things you have to do as a head maintainer of software is to have the ability to say no when that case arises.
That’s the trick - sometimes, if you don’t add the features, you lose share because the market has shifted and now a different set of features are what is valued. So you can either patch and lose focus, or not patch and lose customers.
A competitor comes along who's designed for y + z, and everyone loves how nice and simple it is. Then use case u comes along...