Ok...I think you're confused here. We're talking about where the global configuration files are going. We're not talking about where the packages or the user's own files are going. What you're talking about, Linux itself has no problem doing. If you want the "more careful" approach, all you have to do is build each package from source, ensuring that you point the $PREFIX environment variable to where you want that package to install. If you want to break FHS, there's nothing in Linux that stops you. When I built my LFS system, $PREFIX was heavily used to direct packages to /usr, /usr/tools, /usr/games, /usr/bin, or wherever else I wanted the package to install to using the ./configure script for the source code before running make.
Global configuration files (what the AC above was actually talking about) , however, you don't generally want to have placed anywhere but /etc. This makes system administration considerably easier because the location of the configuration files are now known across systems.
- Where do I go to disable root from logging in to my box through ssh? /etc/ssh/sshd_config
- Where do I go to change a vhost in apache? /etc/apache2/apache2.conf
- Where do I go to fix an acl problem for my dns server? /etc/bind/named.conf.options
See the pattern? If I need to configure something, I don't need to think through "ok, where did this package install its config? /usr/config? /opt/conf? /svr/<appName>/conf?" All I have to do is know the name of the daemon that needs to be configured and then I can do ls /etc...and there will either be an <appName>.conf file or a directory for <appName>. If it's not <appName> then at the very least it would be <daemonName>. Easier on the Admin which is always a good thing, especially in larger administrative environments.