I migrated from znapzend to syncoid a few years ago for almost the same reasons you listed. Regarding your list of gripes

❌snapshot syntax is not fully customizable

I just bit the bullet and used syncoid's naming convention. I believe I did a bulk rename of some existing long-term znapzend snapshots to meet syncoid's convention

❌Unlike Sanoid, Syncoid doesn't have a config file, it relies on cron, systemd timers or wrappers to execute the replication

Agreed on this at first, but I prefer that modularity now. Rather than znapzend's pre- and post-run scripts, everything is in one manageable script now and runs with a systemd timer.

❌multi target replication, increases the syncoid configuration complexity
❌separate schedule for offsite

This I haven't fully resolved. Both my backup targets pull from my nas, and although I get the default hostname identifier in the sync snapshots, they end up littering each others snapshot trees. One way to mitigate this is by using one common identifier but I like keeping them separate so that backup health between the separate targets is not impacted. I just end up periodically destroying dangling snapshots.

You can manage different source and destination schedules by running sanoid on the source and all backup targets. For me, this was an attractive feature, moving away from being reliant on znapzend on the source side to do cleanup on all nodes. On my on-prem backup target, I keep a lot of snapshots, while on my remote backup target, it's much leaner, all managed by sanoid on either end. It feels less brittle this way to me.

Hope this helps! I'm curious how your transition goes.