In package systems that support both a central registry and github (like Rubygems and npm), people publish experimental packages to Github and more stable packages to the registry. Using github as a staging ground for experimental packages makes it easy for users of the packages to keep up to date with ongoing, experimental development, and relieves the package author of the need to constantly publish to the registry just to get small changes to users.
That hasn't been my experience. Rubygems, npm, pypi, CocoaPods, nuget, and bower all use a single namespace, and I'm almost certainly missing some. Flat namespaces are the dominant solution in this space, including in package ecosystems with huge numbers of packages. There is real cost to namespacing, so you'll have to show that all of those ecosystems are ignoring a significant source of real-world problems to make progress with this line of reasoning.
The idea, which still has to be fleshed out, is to allow cases where a single project is broken up into a number of smaller packages to tag those packages with their organization name (for example, @iron or @piston). Those tags would be reserved to the organization, and indeed, they would largely be used for curation.
I personally work on frameworks, and have recently criticized npm for being technically incompatible with certain framework requirements, and even I am clear-eyed enough to recognize that the vast majority of libraries in any package ecosystem do not need the overhead of curation and grouping. When a library is part of a curated whole, I would like to call that out explicitly in the UI, and not have to guess what the semantic meaning of the (proposed) mandatory namespace is.
Policies involving naming are never purely technical decisions. That's why they are ranked as one of the two hardest problems in computer science 
In closing, my personal experience as a user of many languages without namespaces doesn't match the fear you're expressing about a single flat namespace. I think you could make progress in this conversation by trying to crisply identify and roughly measure the costs you associate with the global namespace, so we could compare the cost/benefit on both sides.
I would ask that you take seriously the lack of widespread concern about a global namespaces in many package systems, and try to formulate an explanation for it. Both understanding the real-world costs and the reasons that those costs aren't rapidly identified would help me to square your deep concern with my personal experiences.