You won't find stuff on /lib, /usr, or /bin but even if you did, well it defeats the inmutability if you could just manipulate them, which is pretty much the purpose of nix.
This is my problem with your article, so you can map these files with nice names; now what? want to hack something with them?, then why use a declarative system? want to manually modify them? then why use an inmutable system? It totally defeats the purpose of nix. Thus my opinion, and not trying to be dismissive, that you don't understand what nix is trying to do.
> I suggest reading the comments on the article, which it seems to me are strongly in agreement with my points.
I just did on your suggestion, and I'm not impressed. The top comment is saying that if the OS get's borked they restore from backups, so not interested in software generated paths... which hey, it's a valid workflow if it works for that person, yet the whole point of a declarative system is that you can rebuild your system in mins without any backup.
That's my whole point, I don't care about where the packages are, they could even come from a magician hat, what I want is to be able to write a configuration of the exact packages that I want and that it actually works instead of some mess like ansible/salt/whatever. I don't particularly care about isolation, even if that's kinda the reason why the system works, if I were interested only in isolation or running multiple versions of software I would just use containers.
> In other words: it gives isolation and the concurrent versions, but it does so via more complex packaging tools that need users to learn a whole new programming language, and it eliminates the familiar FHS and replaces it with a new flat programmatically-defined one that is almost unreadable to humans.
I agree that the packaging tools (nix lang and underlying scripts) are complex, that might be something to fix, but I fail to see how knowing the path of packages works to do anything but to encourage the mess that people who love nix try to avoid.