We should not stress the cargo team and the deprecation scheme proposed here seems poorly defined.
We should instead consider adopting a hierarchical crate naming structure in some near future rust edition/epoch, say 2020 or 2022. It might resemble:
All existing top-level crate names become deprecated, except for compiler provided crates like std, core, etc. as well as a few crates like futures that integrate tightly with compiler crates.
I’d personally favor also giving top-level crate names to crates that provide their respective functionality extremely well, including a canonical and elegant interface, so serde and rand, but… I’d foresee disagreement around doing this and it’s not so important. Also, there are many domains like crypto in which one seemingly cannot provide a sufficient interface, making this option impossible there.
We instead reserve almost all top-level names for maintainers, both organizations or individuals, who must first demonstrate control over some relatively limited name resource utilizing roughly sane name, so a DNS name, github or gitlab user or organization name, stackoverflow name with reputation over 1000, or similar.
We’d verify these conditions automatically to minimize the cargo team’s workload. If you cannot satisfy such an automatic condition then you may request a top-level maintainer name manually with a pull request on some cargo-requests repository, which provides a forum for objections.
There are roughly two ways to manage a hierarchical system from cargo itself: We’d likely permit names like RustCrypto/digest but another interesting option would be including a maintainer’s whole namespace, like:
[dependencies]
namespace = "RustCrypto"
sha3 = ...
I’m nervous about this second option because namespaces would commonly overlap and users might become confused as to what namespace they pulled from. We might find tricks to mitigate this concern however.
In both options, we’d expose only the lower level crate names to rustc, not the maintainer name, so we should only need to edit Cargo.toml files for the new edition, not actual rust code.
tl;dr. We can avoid the problem here with only a hierarchical scheme that imposes only a slight complication to registering as a maintainer and modification to Cargo.toml files, and only minimal work for the crate.io team and no modifications to actual rust code. It remains to work out the best modification to Cargo.toml files however.