If you use Alt-m merge-to-centre on two adjacent vertices on the default cube, say the two nearest top vertices, (1,-1,1) and (1,1,1) you get, in effect, a square base lofted to a triangle parallel to the base.

In this resulting wireframe figure, the base and ‘back’ faces are squares; the other two ‘side-faces’ have 4-vertex sides, but are not plane faces. Solid-view rendering, looking e.g. at the left ‘side’, resolves it as a pair of non-coplanar triangles, with two possible ways they can be arranged between the four side vertices. (In my example left and right each resolved differently).

So far so good.

Now, what bothers me is that although these new triangles have an edge between them, this edge does not exist in the wireframe or mesh.

This geometry: (1) cannot be edited, and (2) is ambiguous and can exist in two equally valid solutions, which can flip if the cube is tweaked in other minor ways. This must be a common issue when merging vertices, so how do people resolve it? Thanks.

Join the 2 verts along the “fold” line/s.

Thanks that will ‘fix’ this ambiguity manually.

So, am I right that Blender’s strategy with ambiguities like e.g. non-coplanar quads is that one of the possible solutions is not frozen into the mesh, but left unresolved until solid-render time, when is gets resolved (choosing one solution at random?) so that a hole is not left in the mesh.

That is OK but (1) It would be nice to tell Blender to resolve mesh ambiguities at edit time (even if ugly), and/or (2) Provide a method of highlighting ambiguities so they can be easily spotted and fixed manually.

Anyone know more about this? Should I move this to the developers forum?

Well there is the Triangulate Mod > Apply then in Edit mode select all and Ctrl+J to remove triangles.

In edit mode there is a ‘Split Non-Planar Faces’ command, it is the maximum you can ask for.

Nice. Didn’t know that.

Thanks guys, this thread is now closed.

Brilliant responses, cheers!