[Pre-RFC] DNS domains as package namespaces

I thought of another way to explain it, by analogy with lib.name.

If you have a package at https://crates,io/crates/some-example-lib, the name that will be exposed to rustc is expected to be some_example_lib. The transformation from crates.io package name to rustc library name is simple to understand and can be implemented mechanically.

The lib.name field can be overridden with an ~arbitrary value, for example I could use it so that the https://crates,io/crates/some-example-lib package was exposed to rustc as completely_different_name. This severs the connection between the package named and the library name -- it's no longer possible to predict what the library would be called.

If I were to publish a package https://crates,io/crates/jmillikin-serde-json then the only obvious choice for the name that's exposed to rustc is jmillikin_serde_json. If I were to set lib.name to serde_json then that would be confusing -- it's different from what users expect, and there's no way to predict it. There's no mechanical transformation that can be applied to the string "jmillikin-serde-json" to produce "serde_json" without generating incorrect results for similar names.

The reason to have a delimiter like jmillikin/json or (jmillikin)json is so that the mechanical transformation of a package name to a library name remains possible.

Concerns about the possibility of changing usernames have caused jmillikin-json to be a valid package name but jmillikin/json to be an invalid package name -- the latter uses a namespace syntax, and namespaces can't be usernames, because usernames are mutable.

From the perspective of the crates.io database the strings "john-millikin.com/json" and "john-millikin-com-json" aren't materially different, but to everything downstream of crates.io the difference is important because the former can be parsed to extract the library name and the latter can't.

If you're OK with a package being published with the name "john-millikin-com-json" and lib.name = "json", then why would you not want to allow the semantically equivalent and much easier to work with "john-millikin.com/json" package name?