For me I always point to the Java's time library pre-8 as an example. It was a common pain point, experienced Java devs would know to use joda time but beginne

For me I always point to the Java's time library pre-8 as an example. It was a common pain point, experienced Java devs would know to use joda time but beginners wouldn't know to look to an alternative to the one in the standard library implementation. Over many years and a lot of pain, it was eventually replaced. If libraries are initially kept outside of the standard library they can compete, gain and lose support, and a clear winner will eventually surface. Old patterns can continue to exist and be support without breaking changes while new, better APIs can incubate. In time, after they've proved themselves, then they can be pulled into the stdlib. When it isn't included in the stdlib then a new developer needs to always ask "is this the recommended library?" In some of my projects I'm still using a few libraries that might not be the preferred community solution anymore, they are still very well supported. When a winner becomes more clear then I can migrate. It comes down to two different approaches. Both are valid, both have their advantages. I prefer rust's conservative approach to the stdlib but I understand why someone would rather less reliance on shifting 3rd party libraries.