This may have been discussed ad nauseum already, but as I tried to package turbogears for Fedora/CentOS, I thought I'd throw in 2 cents.
From a .deb and .rpm perspective, it is highly discouraged to install non-system managed files into non-$HOME areas (esp. /usr). Even for many, /usr/local is highly frowned upon (eg. ./configure; make; make install mantra).
I see that --single-version-externally-managed has been added as an option so that .deb/.rpm packaging can take advantage of that relying upon apt/yum/smart to take care of business. Hopefully, this will be pushed out soon. (Because turbogears script generation is not trivial to package. I think I'll just include a generated script as one of the Sources, for now.)
I think the goal for setuptools on rpm/deb-based systems should focus on getting $HOME setup and managed correctly for packages not provided by the system. For example, if I had an ISP which provided python2.4, but not TurboGears, then I could use .egg to manage a setup in $HOME to use the packages correctly. Currently, -d/-s and other options can be used. But, if the user isn't root, maybe it should be the default behavior: install and manage in $HOME.
Also, are there efforts to detect if a package is already installed? For example, if "python-sqlobject" is installed, can setuptools detect the lib if the install_requires has "SQLObject"? I think peering between .egg and .deb/.rpm to be a difficult problem. So, having it all or nothing would be a cleaner policy. .deb/.rpm to manage /usr installed packages/modules and .egg to manage $HOME installed packages.