I have used the “download”… “upload” workaround and it’s fine for the time being, but yes: it would be more intuitive to be able to transfer the files.
Unfortunately, as I’m sure you’re thinking as well, the variety of drives and their implementations make a generic abstraction difficult: I know for example that the GitHub drive can operate purely clientside (if not using an access token, I believe), meaning all requests would have to go through the browser anyways.
Yet, perhaps the solution can be to allow drives to opt in to this functionality (with the incentive that the drive feels like it works “better” when such functionality is either implemented or its impossibility is warned about.) Perhaps instead of buffering the file in the browser, in the event of a cross-drive transfer, a file’s download URL could be passed to the new drive on a “copy” operation (perhaps the name/type of the drive can additionally be an option to “copy” to further differentiate the cases.) The download URL can then be handled clientside (by requesting the download to a bytestream) or could be passed to a server handler. The server handler can then make the HTTP request itself, removing the browser from the equation.
This solution would also scale nicely to instances where the download URL is really a proxy endpoint within the Jupyter server; in that case, the server can loop back to itself, calling the proxy endpoint, which does the complex work of requesting the remote data source. To prevent unnecessary buffering in something like the JupyterHub proxy, some work could be done (if it doesn’t already exist) to automatically route requests back to the user’s server on the loopback device.