No way.
And you never need it. First of all, there is no such distinction. The question simply makes no sense.
Let me also explain that: there is no such thing as "clipboard move". This is a pure application-side part. You just missed the idea. Yes, some applications offer "cut file — past file" operations which is functionally equivalent to "move", but this is nothing but a metaphor. In the OS, there is no such thing.
One example is "moving files". This is how it works: first, application handles "cut files" command and simply mark some files scheduled for the move. It's important to understand that nothing is cut. Next command is supposed to be "paste files". If it is issued before any other clipboard operation, the files are simply moved. If the user does something else, the "cut" command is simply ignored; and the files stay where they were. If the user issues that command, the files are moved. Same things happen to the cells of a spreadsheet, including Excel.
You can develop the same technique in your application. The question is: is the system clipboard even involved? The answer is: yes and no. As in both examples explained in the previous paragraph, your application can be executed in one instance, of several instances of the application process. If it was always the
same instance, using the clipboard would be pointless. But the same application can be executed in several different processes; and the processes are isolated. They need to communicate on this file copy/paste/move activity; and this is conveniently done via the available system clipboard. All you need to implement similar thing is little logical reasoning.
Moreover, as to the file manipulation: you can have multiple unrelated application using Shell API. Not only they are different processes, but even the processes of different applications. And they can communicate through the system clipboard, in this aspect.
That's all.
—SA