This seems to involve every configuration where an extrusion cuts through the revolution point.

When a point in the revolved section lies on the axis of revolution, we generate a Bezier surface with some of its control points coincident. That creates special cases that the surface intersection and classification stuff doesn't handle.

Basically, the NURBS Booleans in SolveSpace should work well on most shells bounded by surfaces of extrusion. For anything beyond that, you're on your own. The mesh operations ("force NURBS surfaces to triangle mesh" in the group's browser window) don't suffer that limit. The particular example here could of course be drawn with no Booleans, in a single operation.

SolveSpace's kernel could be improved; but it's a big task, and relatively few developers can do this kind of work at all. The best existing free kernel (that I'm aware of) is Open CASCADE, whose surface libraries could be integrated while maintaining SolveSpace's constraint solver and user interface, along a fairly clean existing boundary. That would be a pure integration job, but also a big one.

Yeah, that particular configuration fails for multiple reasons. To debug, you could first look at all the generated intersections to see if they're correct and complete, to narrow the problem to intersection generation vs. classification, and then proceed from there, to see what unhandled case (or pure bug; but the former is more likely) is causing that.

opennurbs, on further reading, is a tool set for reading and writing Rhino's data file format. So, it has nothing for creating a boolean between 2 BREP surfaces,
or editing a bezier with different control points. Nevermind....