So the first issue is actually somehow induced after Move and before Connect. Connect itself is a bit odd-fashioned and doesn't do anything with the system cursor. I will add a cursor restore before any command starts (or restarts) as a defence against whatever this scenario is. I do
The overall idea was that the system cursor would be superseded by the blue arrows/markers (when in range). And that applies to the drawing surface (not to the hotbar or command buttons, for example). If (somehow) the cursor is suppressed, the window manager will show it as the pointer position passes off the draw surface and remove it again as it passes on. That is what you are seeing in the second case as "jumping". This apparently is not as well handled in Windows as in GTK as there seems to be an overhang from the drawing area before the cursor comes back. So it looks like I need to add a "guard" that force restores the system cursor when within a short distance of the drawing edge.
What you see instead of the system cursor is the Blue crossed cursor (indicating that a left drag is possible if a click is made). But in your case, that didn't come on at first because you did drag-and-drop (not supported) rather than a select click and then a click on the drawing surface - so logic never gets fired.. It doesn't go off once you accepted the first track with "space" -> because there is a still a track selected on the hotbar and if you clicked again another one would be added and would be draggable.
So, I think the safeguards will make sure we have more ways that the cursor comes back.