There's an awful lot of back and forth in the comments there over whether it should be a specification that defines its requirements in terms of whatever systemd programs happen to do, or whether it should be a specification with its own concrete basis that systemd is held to like everything else.

It should be neither. It should be a set of rules that most people can agree on. If some of that is what systemd does, that's fine. If there are things that systemd does that most people don't agree on, something else should end up in the standard, and systemd should conform to it.

The problem is that systemd evokes some pretty visceral negative reactions in people. I still have mixed feelings about it, but, by and large, I encounter minimal real-world issues with it. Just because systemd has decided to do something that violates the older FHS3/4 standards, doesn't automatically make it a bad thing. Maybe what they're doing is a better way. Maybe not.

The irony is that systemd doesn't really follow what it prescribes in file-hierarchy(7), and expects some files in the "wrong" place. Other software has (obviously) followed suit, so now we're in a world where software follows the conventions that systemd _implements_ to maintain compatibility, rather than what it _documents_.

The most obvious example that comes to mind is /usr/lib/os-release, which file-hierarchy(7) indicates should actually be in /usr/share/os-release.