Synology support assisted in getting to the bottom of this.
If the pathname component is missing a leading "/" (as in: sftpnas:home, rather than sftpnas:/home) there is a bug somewhere in the SSHD programme which corrupts memory eventually resulting in an abort being raised in the malloc/free code resulting in SSHD segfaulting. This causes rclone to report spurious failures (getting EOF for various ops), plus the retry count keeps going up, which seems to show there are problems in the rclone retry code, as it often eventually hangs, even when asked for just one retry.
The simple workaround is always to have a leading "/". Then, it works more or less flawless, other than the spurious "cannot have control chars in filenames" bug. Oh, I still haven't figured out if it should be able to do a checksum or not.
Anyway, given that synology are unlikely to be able to find the malloc issue (well, I think there are some obvious places to look, given that it is sensitive to the leading "/" or "") and even if so they will have to report it to whoever maintains the library or sshd programme, I think it would be good if rclone had some warning somewhere regarding the use of a leading "/" for synology. Add an "is it synology" question or perhaps if there is no leading "/" and it is SFTP?
Not sure, but I have been going back and forth between me and synology for several weeks now until I finally got them to run rclone and they came back with "works for me" and I was able to note that they had a leading "/" whereas I did not.
Also, given that this is most likely a common linux-based SSHD issue, I would expect others to have issues with SFTP.