For the records, I have understood why this doesn’t and potentially can’t work.
It has nothing to do with any mutex or transaction, by the way.
When a file is dropped in-app, i.e. from one window to another (this also applies to the Desktop), the Tracker looks for the current selection in the source window and if the selection is empty it returns doing nothing.
Worse still it does not even check if the selection matches with the refs and just picks up the selected file from the source window ignoring the actual refs in the message.
This can be easily witnessed by manually changing the selection in the Tracker’s source window before dragging the “file” from DropIt! from fileA to fileB for example. You will end up with an unintended file being moved.
I am not sure if this could be considered a bug, in the end DropIt! wants to implement a quite uncommon and extreme use case. Nevertheless, I may be able to work this around by preprocessing the message and turning it into a “foreign drag” in Tracker’s term but looks a bit tricky.
All the more reason to get Haiku devs’ advice here.
EDIT: I may have changed my mind and would actually consider this as a design flaw. This unintended behaviour can be triggered at any time even without DropIt! in the middle.
It’s easy to reproduce it. Take two Tracker windows side by side pointing to folderA and folderB, respectively.
While dragging whatever element from windowA to windowB, close the former with the shortcut CMD-W. Now that it’s gone, keep dragging and drop the file onto the destination window and the Tracker will… do nothing.
EDIT2: Another scenario is as follows. If the selection is changed “in-flight” with the arrow keys the new currently selected element is moved to the destination. Bummer!