I think this mindset is exactly what Rust's stdlib encapsulates, where the differentiator comes is "scope." As an example, most of STD (the stuff outside core)

I think this mindset is exactly what Rust's stdlib encapsulates, where the differentiator comes is "scope." As an example, most of STD (the stuff outside core) makes the assumption that a nonfallible allocator exists. This is an entirely reasonable assumption for any high level programming language... yet it's one of the biggest complaints about Rust's standard library from systems programmers. And so a not-insignificant amount of (mostly volunteer) developer time has been spent modifying very basic data structures and APIs to support the (not so niche) use case of fallible and pluggable allocators. If you're working on a stdlib where the question, "what if my allocator doesn't work" is meaningful, it's not a big jump to much more complex questions about how to implement "standard" features in other languages that simply don't have the same concerns as a systems language like Rust - making it much more reasonable to shove off the responsibility of implementing those features in libraries out in the ecosystem. And I think that's wholly in line with the space that Rust occupies, which is next to C++ (which also has a lacking stdlib for "standard" features), but at least has a good enough package manager to deal with it.