I always thought Unix v7+ should have added some kind way to do atomic groups of syscalls, eg:

  begin_transaction ();
  lstat ("/path", ...);
  lstat ("/path/foo", ...);
  commit ();

In Unix v7 mkdir was not a system call. It was a setuid program implemented using mknod + link. That was racy so the mkdir(2) system call was added. But it could have been solved more generally (and more elegantly) by adding transactions.

It could also solve the whole thing with ending up with zero-length files because you didn't use the right incantation to update a file atomically on ext4 (https://thunk.org/tytso/blog/2009/03/12/delayed-allocation-a...).

A general purpose transactional interface widene the error space to include cross process deadlocks / denial of service not to mention performance issues.

Wasn't making userspace handle these kinds of things a big part of "worse is better"?

Turns out when facing adversarial actors worse is just worse.

Could you elaborate? Seems like there’s a bunch of things that can’t be batched together on an ordinary file, without involving symlinks.

What they (and TFA) are saying is that there is no transactional view of the FS. If you could work in “repeatable read” (only and always see the state of the FS before you started the transaction) symlink races wouldn’t be possible.

Right, but there is no transactional view with or without symlinks.

Without symlinks it doesn't matter, because by definition a symlink race requires a symlink to be involved.