+1
My use case is similar (if not the same), but I'd to phrase it in a different way. I want to be able to disable seeding of a specific folder on a device that has a connection which is either slow or expensive. It would be even better if this could be a default setting when sharing a folder from a super node.
This sort of goes against the idea of distributed shahring that Resilio Sync/Torrents are, but I often want the robustness and reliability of a Resilio Sync transfer in a centralised sharing environment.

Just for clarity, is rslsync running when this snapshot is restored? I assume it's not.
I suppose the question could also be phrased as which files would need to be part of a snapshot to be able to make a Read Only peer be exactly as it was before Peer A removed the file? In this case if Peer A stays offline Peer B should have no way to know that the file was removed and serve it to Peer C.
For what it may be worth, I recently moved the .sync folder on my "main" server into $HOME/.config/resilio-sync (for systemd sanity) and things were a bit wacky until I also moved `.SyncUser*` folders along with the various `.dat` and `.db*` files. If all of these are part of a snapshot I'm sure the time-travel will work.

All settings are default, except bind_interface which is set to a real ethernet port (without it, docker and kvm virtual ports seem to get in the way).
Listening port is not 0, I picked one and set my router to dst-nat it.
As far as I can tell, things work normally and I don't think this causes the idle sync periods (the remote peer has only 2Mbps), but I'd still like to find out what this error is all about.

I saw this line in sync.log:
Can't bind connecting socket 59 to IP 192.168.1.2:0 - 22 Invalid argument
The IP is that of the server running Sync. The connecting socket is, I think, coming from the 1 active remote peer (not in LAN). The peer does get data but it looks like the sync stops for a minute every few minutes.
Is this something worth debugging further?