This is my personal opinion. It should not be taken as a statement from the crates.io team, nor does it imply that anybody else on the team shares my opinion.
I do not think we can just paper over the naming collision between
foo-bar. You mention that we map from underscores to hyphens, but ignore the fact that we very explicitly do not allow two crates that would normalize to the same name to be uploaded. There are two main reasons for this.
The first is that this opens up a potential attack vector. If you take some example code involving
extern crate foo_bar, but accidentally depend on
foo-bar instead of
foo/bar, your code may compile but not be the library you thought you would.
The second is that we have a lot of precedent for disallowing things that could result in “your code stops compiling just by adding a crate”. This is why the orphan rule exists, and it’s also part of why we disallow
foo-bar already exists. I do not think that saying “I am skeptical that it will come up much” is a satisfactory answer here.
More generally, I also would like to see an explanation of why you think that uploading a crate called
foo should grant you special ownership of that namespace. That’s not generally how this sort of thing works. When you trademark a name, that doesn’t mean nobody else can use it as part of their name, just that they can’t use it to try and imitate you.
I’d love to see a little more clarification around the problem this is trying to solve. There’s some vague mention of squatting, but little explanation about how this is connected to squatting. I’d like to see some more clarification around what the specific problem that this is trying to solve is.
Which then brings us into alternatives, which aren’t really addressed at all. Are we just trying to solve the problem of visibility of packages owned by a single org? Is this something that can just be solved by adjusting the UI to make the owning org more visible? (e.g. you can already see all the “official” Diesel crates at https://crates.io/teams/github:diesel-rs:core)
Is the goal to help users figure out whether a crate is made by the maintainers of the main package or a third party? (Assuming that we will remove malicious crates if they are uploaded, why do we think that distinction is important?) Could this be solved by making the owners more prominent in the UI?
There’s also the unanswered question of should this be mandatory, and if not whether it should be opt in or opt out. I know I personally have no interest in reserving the Diesel namespace. I want authors who create plugins for Diesel to be treated the same as the authors of Diesel. If we make this opt-out, what about the authors of less maintained crates who may feel similarly, but not know they have to opt out of this?
I think this is a good start, but there’s a lot of questions that could use more explanation.
I would like to re-iterate that these are my personal opinions, and I am not speaking on behalf of the team.