Not updating is only half or even less problem.
Because crate could be created 10 years ago and not updated, because here are nothing to update, it works perfectly.
But even today they may have users who use it in they application. Who will pay to users of crate for breaking they application if name is reclaimed?
And how often crate is used will depend on how often application who use it is updated.
One fix may be to use crate identifiers. For example if you need to use crate request you would need to write this in your Cargo.toml: author@mmm.com:request
but you wil be able to use it in your code as "request"
In this case here will be: author@mmm.com:request autho1r@mmm.com:request author2@mmm.com:request
unique names. Or something similar.
Here would be many crates with same name "request", but all of them would have unique identifiers.
I think this entire thread is pointless from the start.
Just be creative. Come up with a new name.
I recently came up with names for my crates so I could put them on crates.io. They are memorable, convey meaning, and are short / easy to type. It isn't too much work. Why is "request" a special wanted name anyway?
Actually PEP752 also proposes the use of a hyphen (but yes that means you canβt distinguish a namespaced package from a flat one by just looking at the name).
Python (but really PyPI) has been dealing with an increase in adversarial naming attacks in the past few years, so other than reducing the risk of name collisions, I think the idea is that package name spacing provides the following:
It Allows an organization to reserve a namespace instead of being forced to hold a Placeholder
It Emphasizes that official packages like babel/core actually belong to babel.
But how likely is it that somebody is going to claim e.g. serde-macros or crossbeam-channel in the time it takes to get around to making them? If they do, it's almost certainly adversarial, and could probably get removed from crates.io.
This isn't a very big deal until/unless malware on crates.io becomes a serious issue, at which point we'll need more comprehensive ways of dealing with that anyways.