Is there a list of pros/cons to namespacing somewhere?
Going through dozens of threads with hundreds of messages is not easy.
Having a (kept updated) quick list of pros/cons/problems would help a lot in finding solutions.
What is clear is that the current system is far too prone to abuse, as the many messages asking why there is so much squatting prove.
You can have the best community in the world. It just takes a couple of bad apples to spoil everything for everyone.
Providing a policy that name squatting for economic gain is not allowed would disincentivise the practice for the most part. Offering the name for cash would be evidence to initiate a unilateral name transfer.
One crate states an author of kary@email.com, which is not a valid address of course. Github activity is almost nothing.
Only if the author actually does that. It's far more likely that they'll just do nothing, not even responding.
Therefore, two policies of a) no economic gain b) if the crate does not contain useful code, should be enough to police this. The procedure is 1) to ask for the name transfer from the author 1.1) if money is asked for, provide this as evidence for the name to be transferred by crates.io 2) if no response is received and the crate does not contain code that in any way looks useful, ask for the name to be transferred by crates.io.
Other 'edge cases' could exist (obfuscation through copying the same code across crates or other shenanigans), but does not appear to be a problem at present.
There are two hard problems in computer science:
I haven't seen a solution to #2 that didn't involve human intervention to resolve disputes.
Whilst I’m 100% In favor of solving this issue, the main argument against is, I think , that it could have the opposite effect of what you’re looking for.
That's why I say having a list of pros/cons would help solving problems one by one. Let's have a Jira board for cons to solve. 
I am not saying there are no problems with namespacing, but most of them can be solved with a technical solution, takong the burden off people that could have better/nicer things to do than being judges of the community behaviour.
For example, an upvote system where only a registered developer can cast a vote on a crate could help solve the popularity problem.
Creating accounts (and therefore namespaces) should not be automatic, for example should be vetted by a human, or it should be connected to something with a real cost (like owning a domain or similar), or require some kind of action (replying to an email with some kind of CAPTCHA, or confirming in some other way).
Having a crate published (and maybe upvoted with defined levels) would add weight to the vote.
Creating an organization namespace could require a certain reputation on the published crates, or/and a certain number of crates with a non-zero reputation.
Etc. etc.
With time, the best crates will surface themselves and bad ones will be buried.
They are mostly/all technical solutions that would avoid relying on human intervention or on good will of all the actors.
There will have to be a human factor in decisions, but this should eliminate 90% of the load on them.
As for cargo/the compiler, yes, it's not easy, but I'm pretty sure a solution can be found, like... I don't know, having namespace/crate-name in crates.io that automatically becomes namespace__crate-name unless an alias is provided in Cargo.toml. The current crates could remain non-namespaced but the new ones should have a mandatory namespace, and, slowly, as crates reach a new major version, they get namespaces.
As most of the crates are still 0.x, this could be a good moment to implement it, so the namespaces will start filling up quickly as they reach 1.x and in 3-5 years all the non-namespaced crates will disappear (or be declared obsolete/deprecated)
The way I see it, there are two major cons to namespacing, which I haven't seen anybody solve:
Personally, I also object to namespacing on these grounds:
I want to be clear that I'm glad we're talking about real solutions here - you have a lot of ideas that help mitigate some of the concerns I list.
However, I've seen most of these same arguments before, and I am not convinced that the benefits of namespacing outweigh the costs, here.
I do think action needs to be taken to remove the worst abusers. I also think any policy will be exploited, so I think we must create policies that act to mitigate that exploitation with clear rules targeted at the worst abuse.
Right now, however, I largely come down on the side of 'how thin is the namespace we have?'. So far as I can see, with only ~22k crates published, I very much doubt we're out of names.
Why not a simple rule that published crates cannot be empty >6 months? This would allow devs to reserve names for projects they anticipate being near completion while forcing squatters to do more than simply stake out a name.
I would also suggest that if a published crate has never had a version that compiled within a given time frame (maybe a year) of it's publishing then the name would be recycled.
These are relatively straightforward rules that would account for the most serious offenders without imposing additional limitations or responsibilities on the good faith developers.
I would like to link this Pre-RFC which could remedy some of the pain points associated with squatting:
The idea is to make creating a namespace a bigger hurdle than creating a crate.
Right now you can go on crates.io, create a new crate, upload it and it's done. It's all automatic and fast (and rightly so).
To create a namespace you should go through a more convoluted process, to make it harder and (possibly) economically not worth it.
Creating crates inside the namespace would then be as easy as now.
As for not breaking compatibility, I'm sure a solution can be found. For example using the current language syntax: extern crate tokio::io; use tokio::io::Read where tokio is the namespace and io is the crate name. Same in Cargo.toml: tokio::io = "2.0"
All the current crates would become "fake namespaces" and forbidding to register new non-namespaced crates would limit the namespace pollution problem, while adopting other suggestions in this thread (like removing crates not compiling or empty for 6 months) would free up the namespaces in time.
It's only 22k crates now, like there were 22k packages in NPM 5 years ago. 
For me it's not (just) a problem of naming, but mostly of reliability. If a crate is part of a project with multiple developers or from a dev with good reputation, I am more keen to use it in production, while I can afford to test crates from lesser known developers in personal projects.
I am aware that this could make it harder for sole developers and new crates to become important, but it's similar to what has been done with the nursery and the libz blitz.
This seriously needs more investigation, such useful names have been reserved by this user (who is, in most possibility, a scammer). Any update on this?
No. Someone needs to propose an RFC to change crates.io policies. I'm closing this topic because there's no new information to be shared on this topic until and unless someone opens an RFC.