Yes, and there are some other tricks you can do. The underlying problem is that "fully constrained", to the solver, means "cannot be continuously varied". It

Yes, and there are some other tricks you can do. The underlying problem is that "fully constrained", to the solver, means "cannot be continuously varied". It doesn't mean "there is only one solution". So what you get, for instance, is a point being constrained to a distance from a line that the solver will allow to be on either side of that line, at the correct distance, so if the line moves further than the distance when you update parameters, everything falls apart as the solver picks the other solution. That specific one you can force by adding a construction line between the point and the constraint line, with an absolute angle constraint on the construction line. Because lines have direction (a hidden direction! Got to love critical functionality with no representation or control in the UI whatsoever!) the angle constraint forces the solver to pick only one of the two solutions because the other would make the angle 180 degrees out. There are other problems that are much harder though, that I haven't yet figured out how to work with, mostly involving arcs. It's easy for the solver to flip which side of a circle a tangent constraint solves to, and because in that case there often isn't a fixed angle to work with the construction line trick doesn't work. When that happens on an arc, you end up terminating a line in free space, or wrapping the arc the other way round the circle, or something. I do wish arcs would only allow constraints between their endpoints. What would solve a lot of these cases is a winding order constraint you could apply to a set of points - "make sure these 3 points in this selection order are always anticlockwise around their median" or something - to disambiguate solution pairs, but I dread to think what the UI for that would end up looking like.