Having written a lot of documentation for work, it’s never easy balancing the needs of both technical and non-technical users. More detailed documentation often turns off non-technical users who much prefer a quick fix (a reason why ChatGPT and other chatbots are turning into popular search engines).
Enabling all of the debugging info by default adds system load and is generally only of interest when there’s an issue.
I can’t do better than what’s already written, so quoting from the Unix implementation section:
Syncthing records both the numerical UID and GID for a file and the corresponding user and group names, when they are known. When applying ownership Syncthing will first attempt to look up a local user or group with the given name, and if that fails it will fall back to the numerical UID and GID.
On a related note, UID and GID aren’t guaranteed to be the same, so restoring files to a different system – or one that’s been rebuilt after a drive failure or other major issue – can be unreliable (restored files could end up being owned by the wrong user/group).
Since you’ve been trying to sync ownership, and NTFS doesn’t support the POSIX UID/GID, I’m assuming that your external drives are formatted as APFS volumes. Unless the specs for APFS have changed since I last checked, APFS doesn’t checksum user data so bitrot can go undetected.
If the filesystem or files on the external drive on the sending Mac get corrupted, unless it results in an OS-level error that gets passed onto Syncthing, the corruption will be synced to the external drive on the receiving Mac before it’s likely to be noticed.
So although Syncthing is a fine companion to a proper backup tool, it’s not a replacement for one. The receiving Mac in the other room needs to be separately backing up the files somewhere other than the existing external drive (e.g. another drive, cloud storage).
I previously posted about backup tools in an earlier thread: https://forum.syncthing.net/t/syncing-to-cloud-blackup/21219