I do think that the practices that evolved in early unix, and which are, after a modest amount of evolution, codified in the FHS, are not a good fit to modern s

I do think that the practices that evolved in early unix, and which are, after a modest amount of evolution, codified in the FHS, are not a good fit to modern systems, where software comes in packages, and you want to be able to deal with packages differently according to whether they come from the system package manager, vendors, internal developers, etc. I wonder if we could have a rework of the classic layout where we have /usr/share, /usr/<arch>/bin, /usr/<arch>/lib, /etc, /var/lib, /var/cache, and /tmp, but then inside those, enforce a rule that everything is in a subdirectory named after its package. So you would have dropped your stuff into /usr/x86-64/bin/elricsapp/elricsapp, /etc/elricsapp/elricsapp.conf, etc. Then the customer sysadmins could have simply created those directory, chown'd them to a new elricsapp user, and installed your software as a normal user. You'd either have an astoundingly long-winded PATH and LIBPATH, or have some procedure for collecting symlinks to everything in /usr/bin.