The work involved in maintaining a standard library is things like bug fixes. A larger standard library (or multi versions) means there's more likely to be bugs. You also have performance improvements, and when new versions of the language come out which has features to improve performance, you will most likely want to go back through and refactor some code to take advantage of it. You will also want to go through and refactor to make code easier to maintain. All of this just gets harder with a larger surface.

And the more stuff you pack into the standard library the more expertise you need on the maintenance team for all these new libraries. And you don't want a standard library that is bad, because then people won't use it. And then you're stuck with the maintenance burden of code that no one uses. It's a big commitment to add something to a standard library.

So it's not that things just suddenly break.

Every library is a liability especially in terms of api. There are many example where the first take on a problem within a std lib was a bad choice and required a major overhaul. Once something is in standard library it’s literally impossible to take it back without breaking the world if you don’t control api consumers

Yes, in python they break something at every release now. It's terrible. It mostly is because they remove modules from their standard library for no good reasons.

For example they've removed asyncore, their original loop-based module before the async/await syntax existed. All the software from that era needs a total rewrite. Luckily in debian for now the module is provided as a .deb package so I didn't have to do the total rewrite.

edit: as usual on ycombinator, dowvotes for saying something factually true that can be easily verified :D

> They also failed to initially offer any automatic porting tooling which could have increased adoption.

Maybe it wasn't very good, but 2to3 was there from the start:

https://docs.python.org/3.0/library/2to3.html