Just my two cents: Nix is great, Modules is not perfect, but it is good.
I think that Nix solves a lot of the problems, but will likely take a while to be adopted.
I'm still exploring Nix and NixOS, but I have to say: I really like it.
I've found that a practical solution for my own development work has been the modules project [1].
I'd describe it as a happy medium between manual software management and Nix.
The upside is similar to that of Nix: software with conflicting dependencies can coexist.
The downside is that there is no package management: everything needs to be installed manually and configured with --prefix.
However, I've found that the advantages far outweigh the disadvantages.
For instance, tracking down a bug where software A which depends on B which depends on C, but C1 conflicts with C2, C3... etc, and you need to test all permutations.
In my case, package C was multiple versions of cuda: 3.2, 4.0, 4.1, and 5.0
Testing was, eg:
$ module load environment/A-1.0/B-2.0/cuda-4.0
$ ./runtest.sh
I'd really like to see if cabal is compatible with this setup. Hopefully I'll have time in the next few weeks to look into it.
Quick example of a module file for gsl on my machine:
$ cat ~/privatemodules/gsl/1.15
#%Module
set name gsl
set version 1.15
set prefix /opt
set root $prefix/$name/$version
prepend-path PATH $root/bin
prepend-path INCLUDE $root/include
prepend-path LD_LIBRARY_PATH $root/lib
prepend-path DYLD_LIBRARY_PATH $root/lib
[1] http://modules.sourceforge.net/