I suspect it's not possible to do this using the AWS S3 SDK, and that it never will be unless Amazon adds an official move endpoint to the S3 API. At least for the only other project I'm aware of adding support for this custom endpoint, Duplicacy, they wrote their own lightweight implementation against the raw API.
I'm interested, but realistically probably won't be able to give this the time it deserves (e.g., setting up a dev environment for rclone, learning how the project is structured, actually doing the dev, then addressing all the issues likely to be found) for at least several months.
I've emailed their support for how they envision S3 clients to support their custom extension to the standard S3 API and if they have any tips/plans/resources to make this easier; but I'm not sure that will get anywhere based on their response so far.
Do you prefer using these forums for tracking feature requests or would it help for me a create a github issue to track this enhancement?
FWIW, starting to look into this has given me the impression that I'm trying to use a storage provider with a Frankenstein API that isn't adequately supported by the storage provider; so at this rate I may end up moving back to Backblaze B2 and using rclone with that. It's a bit discouraging to think that every client I may want to use would need to be customized to not incur additional charges if I move or rename a file with a vanilla S3 client less than 3 months after uploading the file.
I think the copy-and-delete method being used to move/rename files should all be happening server-side. It's just that if you move/rename files less than 90 days after creating them, then my understanding is that you're essentially going to be paying twice for those files (until the 90 day clock on the original object is hit) when using Wasabi.