This looks good to me but since I never use the library I would like someone else to take a look as well.
@vespakoen @phkahler ?

@iscgar I just found strange behavior with existing Solvespace. Draw two line segments that share a point, and then constrain the shared point as "where dragged". Obviously all 3 points can be dragged, But one of the line segments can be dragged as a whole - both end points move together with the line. Dragging the other line segment does not work the same, one end of it will not move. I presume this is because the shared point is actually 2 points constrained to be equal and only one of them is constrained "where dragged". I was going to say something about preserving existing drag behavior, but ummm...... yeah.

Draw two line segments that share a point, and then constrain the shared point as "where dragged". Obviously all 3 points can be dragged, But one of the line segments can be dragged as a whole - both end points move together with the line. Dragging the other line segment does not work the same, one end of it will not move. I presume this is because the shared point is actually 2 points constrained to be equal and only one of them is constrained "where dragged".

That's indeed the reason for this behaviour. WHERE_DRAGGED is only placed on the starting point of the second segment (which I'll call s0), and since it can move freely, when dragging its line segment it moves with it. OTOH, the end point of the first segment at the same location (which I'll call f1) is constrained to be coincident with s0, and since the solver isn't allowed to move s0 due to the where dragged constraint, when the first segment is dragged it is forced to set f1 back to be under s0.

It is somewhat surprising to users who do not see two points there and are faced with what seems like an inconsistent behaviour. We can avoid it by introducing some logic into the solver that detects that case (param from a coincident constraint being dragged, while a param on the other side of the equation is not dragged but is part of a where dragged constraint) and rewrites the expression of the where dragged constraint, but I'm not sure if it's really needed.

We can avoid it by introducing some logic into the solver that detects that case (param from a coincident constraint being dragged, while a param on the other side of the equation is not dragged but is part of a where dragged constraint) and rewrites the expression of the where dragged constraint, but I'm not sure if it's really needed.

I think that's unnecessary. There is a related "problem" when something like that is extruded. Both points will form a line in the extrude group and if you constrain against that line it could be against either one of them. Then if you delete one of the underlying 2D sketch lines you have a 50/50 chance of deleting the constraint on the extrusion. That's a really rare thing but I tested it by constraining 5 line segments to an extrude line. When I deleted one of the 2d lines (and replaced with a spline) only 2 or 3 of my constraints got deleted of the 5.

A better option is to actually share the same point between entities, but then we'd need reference counting on point entities. That would be a major refactoring and brake existing sketches.

A better option is to actually share the same point between entities, but then we'd need reference counting on point entities. That would be a major refactoring and brake existing sketches.

Since the issue is only with points, in theory we can just add a new request member which specifies points shared with other requests (so that e.g. a line segment request only generates a single point instead of two and reuses the other point from the previous request), and track shared points separately in the UI so that request deletion works as expected. This approach wouldn't require managing a reference count on entities, and also wouldn't break existing sketches which simply don't have that member.

It would mean, however, that you wouldn't be able to just delete a generated point coincident constraint in order to separate two line segements, and we'd instead need to introduce a "split" operation in the UI to essentially duplicate the point that the user wants to split and unshare the point from the request that references it.

Foce-pushed to rebase on master and resolve conflicts after the merging of #1563.

The merging of #1568 made this umergeable, so I force-pushed to rebase on master and resolve conflicts.