Why on earth would the permissions on /var/lock be something for systemd to decide?
Because – as LWN explains – there no longer is an overarching standards body who makes the decision, so anybody can make up their own.
Debian’s continued use of UUCP-style locking does seem to be more than a little bit dated. The FHS 3.0 is clearly reaching the end of its useful life, if not actually expired.
Reading more carefully I see that the real reason is "the /run directory is created as a tmpfs filesystem specifically for run-time files by systemd-tmpfiles.
I forgot that systemd had been allowed to take over /tmp and /run.
Why on earth would the permissions on /var/lock be something for systemd to decide?
Because – as LWN explains – there no longer is an overarching standards body who makes the decision, so anybody can make up their own.
Debian’s continued use of UUCP-style locking does seem to be more than a little bit dated. The FHS 3.0 is clearly reaching the end of its useful life, if not actually expired.
Seems like Debian is more the outlier here.
Reading more carefully I see that the real reason is "the /run directory is created as a tmpfs filesystem specifically for run-time files by systemd-tmpfiles.
I forgot that systemd had been allowed to take over /tmp and /run.
According to Debian everyone is allowed to take over /run
The creators of the FHS were never an overarching standards body. Despite its name, the FHS is more a set of conventions than a standard.
The closest standard that comes to mind is POSIX.
https://pubs.opengroup.org/onlinepubs/9799919799/