The order of appearance of the constraints determines how redundancies are handled.
PlaneCoincident: the second PlaneCoincident of the same pair or parts is relax to a 2d points horizontal or vertical constraint. The third and onwards are ignored. Any PlaneCoincident constraint will be ignored if there are any pre-existing PlaneCoincident or AxialAlignment.
PlaneAlignment: the second one is relaxed to two PointInPlane or PointPlaneDistance constraint. The third one is relaxed to one PointInPlane or PointPlaneDistance. The forth and onwards are ignored. Any PlaneCoincident constraint will be ignored if there are any existing PlaneCoincident or AxialAlignment.
AxialAlignment: ignored if there are any existing PlaneAlignment or PlaneCoincident constraints
These rules are only heuristics, and can still lead to inconsistent result if your specify the constraints "too wrong", e.g. two plane coincident on two different planes, or two plane alignment on the same plane.
In the following screencast, I've turned off auto re-solve at the beginning, because it is kind of hard to select elements for the second PlaneCoincident if they snapped together. Once the second one is created and snapped, you can see that there are two solutions when I dragged the parts. Because, according to the logic above, the points horizontal/vertical constraint can indeed be satisfied at two different locations. In fact, if you consider plane orientation, there are more solutions. This is a thing with SolveSpace that you should probably be getting used too. It is better to be under constrained than over constrained.
