I'd instead aim for a language that supported interface/trait/typeclasses with a huge standard library of those that allowed writing uniform benchmarks and unit tests to every implementation that shipped simple implementations for some of those and made it easy to use different implementations and experiment with them.
This seems like solving just dependency injection instead of trying to solve every library ever, which seems a much more realistic problem to solve correctly, or at least in a way better way.
Every common X means thousands of complex things. There are over 9000 RFCs (insert Vegita meme). Even more popular APIs, libs, algorithms, whatevers.
Even basic support would be near impossible. A constant race between what constitutes basic and releasing it. (Plus upkeep/maintenance, as things continue to evolve at a rather fast pace.) And if the language enjoys at least a minimal level of successful then a lot of non-stdlib packages are likely to become standard by convention.
It's no wonder that new languages nowadays start with minimal stdlibs.
(I just noticed that there's an SMTP server in Python3! It's ... great, I guess. But there's no DNS resolver library. So either the SMTP client (and now server) packages do not handle anything related to DNSSEC / DANE / TLSA / MTA-STS / DKIM / DMARC and others, or they bundle it. Sure, maybe it's enough to outsource these to the upstream SMTP server and the SMTPd package is just for "testing" ... but, this just shows how arbitrary "commonness" is.)
