@whitequark, updated here

@Evil-Spirit But not the first bug, no?

@whitequark, not yet.

@Evil-Spirit Another bug with dragging:
open bug2.zip select g00a then try to drag the circle around by its center. This worked exactly once for me, and then stopped.

@whitequark, Unfortunately I can't open this file (packed filesize is zero). Could you reattach please?

@whitequark,
I have thought a lot and perform some experiments.
There are seriuos issues with the current selection/hovering logic as it described in https://github.com/whitequark/solvespace/issues/213

when user clicks on the screen where there are many overlapping entities, we actually remember two entities:

• Entity in the current workplane if any, or from the last group in order otherwise. This is what goes into the "group selection" thing, and is otherwise operated on.
• Entity from a request. This will be used when dragging. This way, we can drag e.g. a sketch on which an extrusion group is based, even if the extrusion group is active and overlaps the sketch.

1. We can't use isFromRequest criteria for prioritizing because we can (and want) drag non-request entities: extruded, step-n-tf, etc.
2. We should drag exactly what we are hovering (or exactly equal entity). Not doing like this is reason for if a constraint is selected, prioritize it for starting a drag #174
3. We can't use distance criteria in safe way to decide about entities equality (because distance is depend on entity style width which can be different for source and copied entities)
4. We have to direct-prioritize point hovering/selection (we can't use zIndex criteria or should do it the different for rendering and selection canvases)
5. I have no idea about how selecting/dragging from last group can save situation

@Evil-Spirit OK, I'll think more about it too.

Evil-Spirit@3c8cc2e

The logic to fix this might be something like:
When selecting for dragging:
First find the item that normal selection would use - A
Then while looking for items in previous groups
Only use from a previous group IF the item A is not "noticeably" closer to the mouse.

The challenge is "noticeably closer". Dragging items from an underlying sketch is great but often involves something directly under something in the current group. We can restructure my proposed fix for #174 to allow this but the criteria for "noticeably" will need some help/thought.

I created an issue161 branch off my issue174 branch which almost includes a fix for this on top of the other ones. There is a line which needs the criteria for prioritizing the item that selection would use over an item from a previous group. Right now that line reads:

bool prioritizeStatic = false;

If you can define "static item is obviously closer to the mouse than the other one" and drop that condition in that line it should fix this issue while leaving the previous fix intact.

Remember, dragging uses the same picking logic as selection except that it prioritizes items from previous groups. But to fix this we need an exception to the exception in order to prioritize the normal selection. If the two points are on top of each other we want to prioritize the one from a prior group for dragging. This is splitting hairs.

This really is a corner case ;-)
branch: https://github.com/phkahler/solvespace/tree/issue161
Key function sans magic condition:

// This is different from ChooseFromHoverToSelect() by allowing us to drag
// an entity from a previous group. However it doesn't behave quite the
// same in the current group, so if it fails at selecting a underlying
// entity we shall use ChooseFromHoverToSelect instead
GraphicsWindow::Selection GraphicsWindow::ChooseFromHoverToDrag() {
    Selection staticSelect = ChooseFromHoverToSelect();

    Selection sel = {};
    Group *activeGroup = SK.GetGroup(SS.GW.activeGroup);

    for(const Hover &hov : hoverList) {
        if(hov.selection.entity.v == 0) continue;
        if(!hov.selection.entity.isFromRequest()) continue;
        // determine the group of hov.selection
        hGroup hg = {};
        if(hov.selection.entity.v != 0) {
            hg = SK.GetEntity(hov.selection.entity)->group;
        } else if(hov.selection.constraint.v != 0) {
            hg = SK.GetConstraint(hov.selection.constraint)->group;
        }
        Group *g = SK.GetGroup(hg);
        bool prioritizeStatic = false;
        if((g->order < activeGroup->order) && (g->order > 0) && !prioritizeStatic) {
            sel = hov.selection;
            break;
        }
    }
    if(!sel.IsEmpty()) {
        return sel;
    }
    return staticSelect;
}

I have a feeling the issue here is much deeper. The goal is not so much to prioritize move entities in earlier groups is it? The normal selection logic allows picking things from any group. Isn't the real goal something like "move the earliest (in group order) item that is linked to and will end up moving the thing I'm hovering over"? That is a very complex thing to get right and the code to do it thus far is very simplistic, though I think with the 174 fix it's rather effective.