Whoops, I realized that my discussion of question B in the original post has a dangling reference to a “Problem A”. This is the result of cutting and pasting from a larger document where I was musing to myself about Booleans. Problem A is:
Sometimes input will have cases where the intersections have “coincidences” (sometimes called “geometric singularities” - matching verts, verts on edges, verts on faces, edges on edges, edges on faces, faces on faces) or near coincidences. The user expectation is that if these coincidences happen between the parts of the mesh that are being intersected, those special cases will be recognized and make their way into the geometry of the output. Sometimes these coincidences are exact because, e.g., they happen in some orthogonal-to-axis plane and one can construct geometry with exactly matching coordinates on that plane. Other times they are “close enough” that the user would consider them coincidences. Either they placed them there by eye, or some other Blender calculation inexactly place the coordinate there (subdivision of a non-axis-aligned edge, for instance). Users would expect that such “close enough” cases get recognized the same as the exact case.
As a practical example of this, take a default cube, copy it, and rotate the copy by 45 degrees about one of the edges. In the user’s mind, the edge rotated about will match up exactly with the edge on the original cube, and the faces perpendicular to that edge will be coplanar with the corresponding faces of the original cube. Neither of these is true in the current way Blender works (in fact, surprisingly, even the 8 vertices of the default cube do not all have exact +1 or -1 coordinates!). Yet a user would hope that a “union” boolean would make one face each out of the overlapping coplanar faces on each side. If you use exact arithmetic, this will not happen.
(One could take the approach of the current BMesh boolean code and just say “we don’t handle such cases”; but wouldn’t it be nicer to be able to handle them?)