/package does the same thing, and does it much more reliably. FHS doesn't actually let software and users confidently access files; /package does.
Example: Is the lynx configuration file in /etc/lynx.cfg, or is it in /usr/local/etc/lynx.cfg? With FHS, software and users can't tell. The answer depends on whether lynx was a ``system'' package or a ``local'' package.
In contrast, /package provides names that don't change when ``local'' packages are integrated into ``the system.''
Another example: Is the statistics program in the hylafax package called xferstats, or xferstat, or xferfaxstats? With FHS, software and users can't tell. The original xferstats name was used by a different statistics program in the wu-ftpd package; one OS distributor resolved the conflict by changing the name to xferstat; another OS distributor resolved the conflict by changing the name to xferfaxstats.
In contrast, names in /package are globally allocated, so conflicts don't happen in the first place. This is one of the essential features of /package.
Here was my sarcastic response:
Yes, that's a very important principle! Let's take, for example, csh, which uses /etc/csh.cshrc and /dev/log and /bin/sh and many other files. The reason that all those filenames are listed in /etc/csh.conf is so that they can be changed. Now, some people want to move /etc/csh.conf itself. That's why csh looks for the /etc/csh.conf filename in a hashed /etc/registry.db file. Of course, on some machines, we need to move /etc/registry.db. That's why the registry filename is listed in a COMPILEDFREGISTRY environment variable. There's still the possibility of conflict with previous uses of the COMPILEDFREGISTRY variable. That's why the name of that variable is listed in /etc/fregistry_variable_name.txt. You say you want to move /etc/fregistry_variable_name.txt? You fool! We have billions of programs that read /etc/fregistry_variable_name.txt at the top of main(). Everything _else_ has to be configurable, obviously, but /etc/fregistry_variable_name.txt isn't going anywhere.