Unison is very robust, much faster (Syncthing extremely slower than unison) and actually very sophisticated and optimized. It does compare file chunk hashes etc. But it simply relies on plain old ssh and has no support for device discovery, dynamic IPs and relays.
You made me think, but even for the (advanced) user that would have to manually install unison, and enable it somewhere in the advanced settings for a device, there wouldn’t be much of a change in how syncthing is used, would it?
It’s just about calling unison as an alternative syncing backend if possible (when installed), allowing to make use of some of its features, or serving as a confirmation or check.
I could help with finding appropriate unison (configuration) profiles.
The ideal command may be a combination of calling unison over a autossh connection http://www.harding.motd.ca/autossh/
Unison synchronizes two devices, at a single point in time. Syncthing synchronizes across multiple devices continuously, each of which may go offline and come online at various points. They simply are not interchangeable in the way that you’re imagining.
There’s no such thing as a backend as you think of it in Syncthing, so this is not exactly pluggable. However a script around unison might do what you want.
For some time already unison has gotten support to do continuous filesystem-watch driven synchronization, and can be used to sync multiple nodes in star or chain topology.
The problem with unison is the missing device pairing, discovery, and relay part, where I see syncthing is able monitor and re-establish the connections to the peers going on- and offline.
I hoped it may be possible to let syncthing alternatively monitor (for testing and unison usage) a “custom sync command” that may be executed once the peer is resolved, and exits when the connection breaks.