Then you can mode the files away explictly upon successful upload. You do not need support for the in WinSCP.
Sample code, I have not tested it:

Our scenario was a put to a remote destination. We wanted to archive successfully copied files to another location on the *local* side (e.g. copy to remote, upon succes - move to, say, ./copied) That way, if the remote side disputed the validity of our copy we had another handy. In addition, it allowed us to move successfully copied files out of the local transfer directory so that we didn't copy them out on the next cycle.

Long and confusing description I know, but that was the reason for the request for -archive

You are correct about synchronization. I guess I was thinking of this in the context of get/put. Remote recycle bin might work for that purpose. Curious if there is a way to configure it in script?

It does not make a sense for synchronization. If you synchronize you want the local and remote directory to bt the same afterwards. If you delete (move elsewhere) synchronized files, that's not synchronization anymore. It's mere move of remote files to local directory, isn't it?

Anyway, you can configure remote recycle bin and use "get -delete" command in scripting.

This would be nice to be able to archive successfully downloaded files instead of deleting them. If something happened during transfer, it would be available still, in case a re-download was needed.

I would love to see a -archive option, similar to -delete for scripted synchronize, except that files that are successfully synchronized (or get or put) are moved to a different directory. That would allow, for example, synchronize local -archive=./archive

With this, if the local file is removed manually, a new copy is not re-downloaded.

Or perhaps this functionality exists, and I'm missing it...