Noah pointing out that PyPI doesn't really have any solution to this problem I think is an indication that they don't really have this problem in the same way that we do.
As an example of same problem on pypi, there is "netifaces" package:
First there was a "netifaces" package (linked hosted on a private server). His maintainer doesn't accept any patch, so someone create "netifaces-py3" for python3 compatibility. But this one does't answer to any new PR, so someone create a "netifaces-merged" to merge py3 + fixes.
About namespace, it's really important to have a "main" namespace. It's a real difference over puppet and lead to a better quality of community repo.
Moreover, with berkshelf you can use your own cookbook from git really easily and lead to a "private" namespace.
In my opinion, debian / ubuntu / ... repo are the "old way". You don't trust upstream and do your best yourself to manage dependencies problems.
pypi / rubygems / ... are more like "do what you want". Democracy + PR will lead to a working system. And it works!.. with some help of "environment" (bundler / virtualenv).
In chef case, berkshelf + dependencies is our response to "environment", but we can do more. jenkins-ci plugin repository is a good example:
any upstream people can push a plugin, but sources are stored in a "jenkins-ci" repo with policy and CI integration. You don't have a "myRepo®" conservative behavior (for public publicity) who can block many maintainers to give ownership (true story).