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.
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/
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