FAQ says, "If the conflict is between a modification and a deletion of the file, the modified file always wins and is resurrected without renaming on the device where it was deleted."
But that's not true for the sync-sub-directories, which is why I asked the question. Instead, when the overlaid mount is removed and the naked directory under it is exposed, all the files are deleted on all the peers. ! This directly violates "Design Principal #1" of Syncthing (keeping user data safe).
If we accept the limit "You may not have overlaid mounts anywhere under a sync directory," that's a pretty bad limitation. And if it ever accidentally gets violated, we loose all the user data? Ouch!! I can't trust a system with such a potent latent problem.
The unison developers thought through how to handle USB mounts and dismounts and I think that's an almost perfect match to overlaid mounts. In the linux world, I think mounts would show in the mount table. In the windows world, the concept is not a threat because there are no overlaid mount points - just drive letters that pop into existence or not.
..the reason I'm trying to do sync with subdirectory mounts is to build a tool chain to answer the Syncthing #1 feature request: encrypted syncs. This is already possible with encfs "forward" syncs, but with "reverse" syncs, the encrypted data is virtual so it pops in and out of existence based on when ecnfs is running. I can't have a dismount delete all of my files on all the servers if I unintentionally stop encfs with the sync running.
The reason I don't want to mount and dismount at the sync root level is because the root level of my sync contains UNencrypted tools like encfs, Synthing, TrueCrypte, BTSync, 7zip, etc. Of course, they have to be cleartext so I can access the encrypted data. I also want my TrueCrypte volumes to live at that level, because there is no reason to double-encrypt them. I need the data root directory of my encfs encryption tool to be one layer down.