Perhaps not everything should be packaged the same way, but one key advantage of the "one package system to rule them all" approach is that it really simplifies THINKING about your package installation needs. For systems composed of many pieces being able to "apt-get install <everything>" beats having to go npm for one item, pip install for another and then gem for a third.
Given that there are generally a common set of requirements for package management one possible solution could be virtual repositories. I almost exclusively use Ubuntu/Debian: you could have a repo that LOOKED like a standard apt endpoint but translated all the apt requests into the appropriate npm/pip/gem/<language of your choice's package management system> without having to manually bake the .deb files. Updates to the backing repo would be seamlessly supported, so an 'apt-get -y upgrade' would update everything. Integration with virtualenv-style local packages would involve some magic, but having only one set of "package management primitives" would be pretty awesome.
I fear the problem is distributions can't agree on how to do it. If there were a common "virtual repository" standard then the npm/rubygems/etc. maintainers probably wouldn't mind implementing it - but actually they'd have to expose an apt endpoint, and also a yum one, and a portage one, and...
Debian seems uninterested in working with standards it doesn't like (see their "support" for installing LSB RPMs), and other distributions won't want to introduce the complexity of APT, so I unfortunately see little way forward for this.
I think this makes a lot of sense. I used to be a proponent of everything being a .deb or .rpm, but I've come to realize that certain things just can't be packaged reliably on that level.
I know a whole slew of people who refuse to try out node.js because npm exists and they can't (well maybe 'really shouldnt') install those packages with apt-get.
I've yet to see a reliable up-to-date OS vendor distribution of node.js itself, much less all the packages.
From what I understand, node.js packages are not, in most cases, intended to be installed systemwide. You can install them to a system directory (with the -g option), but by default, it assumes that you want to install to your current project, in the cwd.
The Nix (http://nixos.org/nix/) approach to package management really seems the future to me. To sum it up, it allows multiple versions of the same libraries to live side by side and therefore prevents dependency hell.
Given that there are generally a common set of requirements for package management one possible solution could be virtual repositories. I almost exclusively use Ubuntu/Debian: you could have a repo that LOOKED like a standard apt endpoint but translated all the apt requests into the appropriate npm/pip/gem/<language of your choice's package management system> without having to manually bake the .deb files. Updates to the backing repo would be seamlessly supported, so an 'apt-get -y upgrade' would update everything. Integration with virtualenv-style local packages would involve some magic, but having only one set of "package management primitives" would be pretty awesome.