This is a lot to wrap my head around, so excuse me if I miss something that to you may be obvious but...
I don't understand why you think modtime isn't a good candidate (in combination with others obviously). I would think it would be very rare for a file to have its modtime updated and yet not have any of it's contents changed. Yes, it could technically happen I suppose, like making a change to it and then reversing it after. Then you could end up with a binary-identical file with a different modtime. But if this happens and it causes the comparison to fail when it shouldn't in rare cases, is that such a big problem? As far as I understand the only thing that would happen is that sync ends up re-transfering that one file rather than more efficiently moving the existing one. As long as we don't risk losing data that occasional inefficiency seems like it would be perfectly acceptable. And the more factors we can include in the comparison the less risk we have of an actual serious error of a false-positive where a file that should have been synced does not because it is confused for another. To me that seems like it would be a good tradeoff.
Hash we can't use in this context because of the reason you stated for crypt remotes, so if we could use all of name/size/modtime that would probably be "accurate enough" I think - for users that consent to the risk by enabling such an alternate comparison method.
I don't know what a "leaf name" is or if/how that would be different from a filename... can't easily find something on google to explain it. Feel free to illuminate me if you want.
I assume by experiment you mean changing the code myself. Have to admit that is intimidating, but that is such a short snippet that I might actually comprehend it even though I've never touched go before =P But that would involve having to set up all the devtools to edit and recompile go code I assume. I might conceivably be able to do that, or at least try, especially if there exists some sort of list or guide for what I will need to have for the job.