Currently we generally have a trade-off between: - The standard library, which is both trusted/blessed and perma-stable - A package ecosystem which is neither I would love to see more exploration of the space in between: - An extended stdlib which ships versioned libraries which use semver rather than being perma-stable. - Better support for managing verification and assurance of package ecosystems.
Half of the point of an stdlib is that it is a single shared lib so you don't run into the all-too-common problem of having multiple versions of the same lib in your program. Either you bundle all the stdlib multiple times OR you need to rely heavily on complex dead-code-removal which increases startup time (and still have a lot of duplicated binary blob from different versions peer dependencies).
This is why stdlibs almost never _actually_ remove stuff or make breaking changes, because that would make existing programs not compile on the new version of the compiler. This is why in Java you can still call Date methods that resemble the ones present in Javascript (.getYear(), .getMonth(), etc). They were deprecated in JDK1.1 (1997) and still available, today. The alternative is to go through a python3 moment at some point.
Semver the stdlib makes it not that much better than using 3rd party packages.