I guess some of this could go in the support forum. I did not write every step I took so it won’t be easy to reproduce, hence the “User Story”
Here is the deal. I had one instance with “Local state Files 6729 Dirs 1476” under /var/autofs/Files/foo, share named “Bar” (there is a foo/bar subdirectory) It was waiting to share with a mirrored machine.
The mirror machine is a clone. I cloned the OS and the data. I took special care of deleting all .pem files in the case of Syncthing so that the machine has its own identity. That instance had the same configuration, “Local state Files 6729 Dirs 1476” under /var/autofs/Files/foo, share named "Bar" and was waiting to connect to the 1st machine.
Then the “Folder ID” thing was invented, and the 2 machines had a different folder ID for the same path and same data.
Then I connected the machines. I had the great idea to put the first machine, which is in production, in send-only mode.
Then I sent the “Bar” share from the 1st machine to the second one. There was a wimpy warning notice that the receiving path was a subdirectory of an existing share on the 2nd machine. It was not a subdirectory. It was a full clone share already defined on that machine. The folder ID was different.
So I hit save and all my local files were gone. So much for avoiding the initial transfer. I don’t know what would have happened if I did not set the 1st instance to read-only.
The “Folder ID” comment on a share reads "Required identifier for the folder. Must be the same on all cluster devices." FTW are “cluster devices”, now? Shouldn’t the comment rather read “SAME FILES BUT UNDER ANOTHER FOLDER ID WILL BE DELETED!!”?
It seems obvious to me that in case people want to share a large amount of data, they will if possible bootstrap the mirror by making a local copy before setting up the mirror. It would be good if a) Syncthing would somehow refrain from removing 100% of the files in an existing share without warning, b) a how-to was added to the documentation.