Yeah, and this is one of many things the platform metapackage could solve. If we end up not providing it in the default installation, this may be one specific problem we do not solve - you'll need to do at least one more step to get the common components necessary to do simple things. But that step might be as simple as adding a one liner to your Cargo.toml pulling in an unofficial collection of common crates. It's not as simple as it could be, but still an improvement over the status quo.
Shipping a platform metapackage by default in some distributions (Debian) but not others (rustup) seems ineffective since nobody will be able to rely on it being available.
This is one avenue yeah, but even if we go this sort of minimal, interface-heavy route, I am always inclined not to literally put (big) new things directly in std. For example, I don't want anything related to databases in std. If we were to define e.g. an ODBC-like interface for Rust and distribute it to everyone, I would want it in a different crate. At the same time, the way we distribute std is basically an artifact of its develeopment process and that it has unstable hooks directly into the compiler. Any crates 'above' std I strongly prefer to distribute through our standard mechanism (cargo).
Yeah, this is something we can do, and part of the intent - having a path from 'new crate' to 'crate listed in an official directory' to 'crate that is an official part of rust' gives us increasing leverage over various quality issues, improves the quality of the whole ecosystem. And as objective criteria it shouldn't cause too much teeth-gnashing about favoritism.
Lots of great feedback here. Thanks, all.