As for edge cases, I will also try to document that more. In general, when I'm not sure what semantics to go for, I try to either copy what rsync does or do something safer. For instance, one thing I am looking at now is the best way to handle cases where a source path cannot be represented on the target filesystem or where two source paths would collide (e.g. due to unicode normalization or case insensitivity). Tentatively, my inclination is to try to fail before copying any files when possible. Currently, syq doesn't do this (but neither does rsync).
For me, the killer feature would be "ease of use."
Sure, I _can_ make rsync do any number of rarely-used optimizations, if I feel like studying the manpage for half an hour and figuring out how to fit it to my exact use case.
If your tool has the same features but is automatically adaptive -- I'd use it.
Copying thousands of tiny files in deeply nested subdirs? Just works. Copying a huge file that's already encrypted? Just works. Copying a mix? Just works.
No special flags to set, zero config. It just works, optimally, every time.
"Reducing the user's cognitive load" is the killer feature here.
Some suggestions for improvement for your website/Github:
- I wanted to understand how it differs from rsync. A comparison page would be helpful.
- A comparison to rclone would also be interesting, as it also uses multiple parallel connections.
- As it target more advanced users I think it would be helpful to provide more advanced technical insights on how your transfers exactly work. Also how are edge cases handled, what tests are done? Moving and copying files is critical, and you need to inspire trust in your project among users.