And not just at the same time, but over time. A programmer builds a lot of the foundation code and knows all the nuances of that code, but then he moves on and another takes his place who only understands the basic APIs, not the nuances of the code underneath, and that's how things slowly start to fall apart. One can argue this is more the fault of the first programmer than his replacement, since ideally APIs should "just work" without mastery of the nuances, but this is rarely the reality.
And then yet another lead developer comes in and decides to depreciate the "old" APIs and replace them with something he thinks is better, and soon you just have a big mess.
I know, I've been there, and I personally preferred working on smaller projects that I had more way more control over. The bigger projects where my code had to compensate for all the faults in other people's code, that was not so enjoyable.
I think it is almost inevitable when a program becomes too large; especially when you keep piling stuff on it without having a clearly defined 'final end product'. I wouldnt even be surprised if a significant part of the New Era thingy is rewriting a ton of stuff to prevent the entire new thing from collapsing onto itself. Until then I dont expect much in the way of bug fixing beyond the most crucial stuff; it is from their pov a waste of time if that 'fixed code' is going to be replaced anyway.