It would appear that your primary takeaway is that we put stuff in a different directory, for an apparently arbitrary reason. I agree, that would be silly -- if

It would appear that your primary takeaway is that we put stuff in a different directory, for an apparently arbitrary reason. I agree, that would be silly -- if it were the case. With /usr/local/{bin,lib,include}, how would you install multiple versions of openssl? Would you violate convention and do something like /usr/local/openssl-x.x.x/{bin,lib,include}? How do you avoid file path conflicts? When a package is built against a particular version of openssl, how do you ensure that version of openssl sticks around, and that that, upon execution of said program, the dynamic linker loads specifically that version of openssl and not one of the others? While I encourage you to consider those questions, the short answer is "you can't". At least, not with conventional package managers like Homebrew. Because Nix builds each package in a unique prefix (governed by the hash of all of the build inputs, recursively), the Nix package manager can use chroots (and Sandboxes on OSX) to ensure that packages are deterministic, and that each package refers specifically to the versions of the dependencies they need (dynamic libraries are fixed via rpaths and we apply patches for references to executables -- so "python -m foo" becomes e.g. "/nix/store/<HASH>-python-2.7/bin/python -m foo"). If you don't use a unique prefix per package, the problem of "how do I install stuff without worrying about path collisions amongst the multiple versions of requisites" becomes intractable. Ditto for build determinism, binary caches, lightweight environments a la nix-shell, etc. I suppose we could shoehorn each package into /usr/local/<HASH>-<NAME>-<VERSION>/{lib,bin,include}, and then we could tick the "use an existing directory under /" box, but is that really better? I don't see what we gain from that, since that's already an abuse of /usr/local.