if it happens during the sync you could be arbitrirly broken.

Only if the sync is the equivalent of:

    rsync [...] /dev/shm/.browser ~/.browser

Instead of:

    rsync [...] /dev/shm/.browser ~/.browser.new && ln -sf ~/.browser.new ~/browser

Or some such equivalent, i.e. doing the full sync and then atomically juggling a symlink around.

that creates many more writes to the ssd.

Does it? Consider this scheme: maintain two physical directories, one of which is current (and is named by a symlink) and the other of which is old. When doing a sync, you rsync the newest data into the old directory, then update the symlink. It'll probably result in somewhere between 1x and 2x the writes as the non-atomic single-directory scheme, depending on how well adjacent diffs combine. It will also result in twice the space used (barring some very clever filesystem).

He should have used --link-dest= on his rsync.

    PREVIOUS_BACKUP=$(cat ./prev_backup)
    NEW_BACKUP=$(date +%F_%T)

    rsync --link-dest=$PREVIOUS_BACKUP /path/source /path/dest/$NEW_BACKUP

    echo $NEW_BACKUP > ./prev_backup

This will copy /path/source to /path/dest/$NEW_BACKUP (which is a time stamped folder). But it will take into account the previous backup. If a file hasn't changed, it will create a hard link. If it changed, it will then copy the whole file.

And that's it.

Since it's the name is a time stamp. When you need to restore, just read ./prev_backup or just list the directory content, sort it and read the last entry.

This isn't really the sync daemon's fault; it's Linux's (or rather, ext4's, and the Linux VFS ABI's) for not supporting multi-inode filesystem transactions. NTFS has them; APFS will have them. Linux should add them too.

The sync daemon could sync with hardlink and then rename which is atomic.

That would require rewriting the entire directory.

hardlinks for the stuff not changed. Browsers of course, should move to append only file formats.