The purpose of /usr/local is for you to put stuff there, but it actually causes a lot of problems if a package manager does it.

- your work-issued laptop might have work stuff installed in there, and the package manager will overwrite it

- build-from-source package managers like fink/ports/brew are incapable of controlling themselves and always install things you didn't ask them to

Since /usr/local is in the default search path for your compiler, that last one means your personal configure script runs are not reproducible, and you'll start linking to packaged versions of libiconv or whatever without meaning to, and your code won't work on other machines or it'll crash unexpectedly.

Fink invented /sw for this, MacPorts uses /opt which I think they got from Solaris?

> That's the purpose of /usr/local.

I think you must have ignored a substantial portion of my comment. Let's take a look at what (part of) my Nix store looks like (you'll see it fundamentally looks nothing like /usr/local):

  /nix/store/2mmvks92lx37xghj0795ldzrg50lh2pg-bash-4.3-p42
  ├── bin
  │   ├── bash
  │   ├── bashbug
  │   └── sh -> bash
  └── share
      ├── info
      │   ├── bash.info
      …   …
      └── man
          └── man1
              ├── bash.1.gz
              └── bashbug.1.gz
  
  /nix/store/8g6gb6r49fxsrp547rdi3zr06vd69khq-git-2.7.4
  ├── bin
  │   ├── git
  │   ├── git-cvsserver
  │   ├── git-http-backend -> /nix/store/8g6gb6r49fxsrp547rdi3zr06vd69khq-git-2.7.4/libexec/git-core/git-http-backend
  │   ├── git-receive-pack -> git
  │   ├── git-shell
  │   ├── git-upload-archive -> git
  …   └── git-upload-pack
  

Note that each package under /nix/store is its own prefix; that is, it contains its own bin, lib, share, etc.

/usr/local is a dumping ground "for use by the system administrator when installing software locally"[1]. If you need multiple versions of automake installed: tough luck, the paths collide. If you need multiple versions of Erlang: tough luck, the paths collide.

Would you like to be able to rollback your system by changing one symlink[2]? Too bad: when you last installed packages into /usr/local, your package manager clobbered the previous version.

Technically, we could make /usr/local a symlink forest pointing into /nix/store, but we don't: we want to make sure that only the packages we explicitly declared are picked up by build tools, rather than defaulting to searching through the currently "installed" packages.

> /nix/store? Really? You can't just make up new root level directories. That's so wrong.

Can you substantiate your claim? Note that "it doesn't feel right" doesn't count as a rational criticism.

[1]: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHI...

[2]: This probably sounds like a bold claim. I tried to explain how this works above, but if you don't believe me, feel free to ask and I'll explain further. Alternatively, feel free to read the first paragraph here: http://nixos.org/nix/manual/#sec-profiles

Funny that you should mention the FHS. From that same document:

Applications must never create or require special files or subdirectories in the root directory. Other locations in the FHS hierarchy provide more than enough flexibility for any package.

They really should be using /opt:

/opt is reserved for the installation of add-on application software packages.

A package to be installed in /opt must locate its static files in a separate /opt/<package> or /opt/<provider> directory tree