hope not tied to SystemD

putting aside for a moment the standard itself, I see no way in which a filesystem hierarchy standard can be "tied to" a system layer implementation (term used as coined by Benno Rice, I believe), especially not merely an init system inside of such. it isn't even implemented by the system layer, it's implemented by the OS or distribution.

a FHS like this one can only be judged on 1) whether it allows various administrative practices you or others mind need, and 2) vibes.

this FHS is very similar to the old LSB FHS, I see no problem on either front with it. ISTM that the major difference is some simplfiication (usr-merge, no sbin), but many distros and admins (myself included) have already chosen to do that anyway, so it's not very strange.

ISTM that what we see here and elsewhere is a pre-judgement kinda thing, where the UAPI group is guilty of being a systemd-specific space, because the specs they work on are based on prior insight gained by implementations in systemd, and because there's developer overlap. but this seems at best needlessly unfavorable—skimming the standards, they're clear that prior art is systemd, yet do not depend on it (consider, for instance, BLS, which has been implemented in GRUB, or UKIs, which can and are used without systemd).