Does this work? If I have an inner an an outer polygon on top of each other, I assume, shift-click dragging somewhere in the inner polygon will still move both polygons?

Also, I have slight concerns thatself._contains can be expensive and_onmove is called often, which may lead to noticable lag during dragging.

Overall, I suspect that the approach should be slightly different, e.g. determine the polygon to manipulate on mouse press - likely you should click a node or edge, and store that information for the subsequent _onmove.

Does this work? If I have an inner an an outer polygon on top of each other, I assume, shift-click dragging somewhere in the inner polygon will still move both polygons?

When the pointer is over two overlapping polygons and on both of them, both will move - if the pointer is only over only one of them, then only that one will move. Not the best, but better than the current behaviour, where all selectors will regardless of where the pointer is.

Also, I have slight concerns thatself._contains can be expensive and_onmove is called often, which may lead to noticable lag during dragging.

When I run the example above this is fine, but it may not scale well with the number of selectors... This could be moved tokey_press handler but the potential performance issue may occur when pressing key.

Overall, I suspect that the approach should be slightly different, e.g. determine the polygon to manipulate on mouse press - likely you should click a node or edge, and store that information for the subsequent _onmove.

I don't think that the selector have a "selected" state, and once they are drawn, they are always selected. This may be the best approach in this case. Will it be appetite to use this approach?

Not the best, but better than the current behaviour, where all selectors will regardless of where the pointer is.

Agreed. One could do better, but it's an improvement over the current state.

When I run the example above this is fine, but it may not scale well with the number of selectors... This could be moved to key_press handler but the potential performance issue may occur when pressing key.

I'm more concerned on complex selector shapes. The point is thatkey_press is only executed once, but_onmove is a continuously updating function - it should be in the low-10ms regime, whereas, it would be ok in complex scenarios whenkey_press takes some 100ms.
Note: a quick timing of a path with 100 points takes ~ 70µs to contains-check, so this might be fast enough. Though I feel a "selected" state is architecturally cleaner than always checking whether the move event is in the polygon? (e.g. can it happen through glitches/fast movements that mouse and Polygon get out of sync and the mouse slips out of the polygon, which would result in loosing the grip).

I don't think that the selector have a "selected" state, and once they are drawn, they are always selected. This may be the best approach in this case. Will it be appetite to use this approach?

What isthis? A "selected" state - yes I belive this makes sense.

I added the "selected" state to the polygon selector - the handle are visible only when the polygon is selected.