Hmm, this is a possible interpretation of the required behaviour. Could anybody please test this on Apple to see what they are doing?
I found that Apple seems to disregard that mask when doing a drop, so I am not sure what they are doing with it during the drag. One possiblity is that they just use the mask to determine the drag icon (indicating the possible drag operations).

yeah i'm aware of that, and set it up in my program to override the default draggingOperationMask (I just implemented the draggingSourceOperationMask:forLocal: function instead so it would work with older gui's)...

before OS X added -setDraggingSourceOperationMask:forLocal: their default operation mask wasn't documented so I assume when you added it you changed it to align with theirs.

the bug as I see it is more that when you return NSDragOperationNone in the dragging source, it still sends it to the dragging destination, so effectively if the remote dragging destination supports NSDragOperationNone it would be possible to drag and drop, that seems counter to the intention of returning NSDragOperationNone.

not sure if this is a bug but when debugging a DBModeler dragging issue, the default -draggingSourceOperationMaskForLocal: return value for remote drags changed from NSDragOperationAll to NSDragOperationNone

i noticed that the remote side/dragging destination (Gorm) was receving a drag operation with NSDragOperationNone in -draggingEntered:

it wasn't coded to do anything with such an operation, and to me it doesn't seem like it should be getting to the remote side

any old tableview data source which implements -tableView:writeRows:toPasteboard: without changing the default operation mask should be able to reproduce.