It's not anything easy to fix. It's a known issue with the NURBS backend. The workaround is to use mesh.

One can dream. Is there some sort of master issue no. to track NURBS issues?
I could find several, but all showing "corner" cases.

Not really. Fixing the NURBS backend is a many man-years problem requiring the sort of highly specialized experience that cannot be easily contracted out. At least, I wasn't able to find anyone with a set of skills even remotely approaching what's required to make the NURBS boolean code robust. Even if I did, the SolveSpace project does not have the sort of budget required to fund this feature.

Some time ago I was also looking into this, and stumbled upon your question here: https://softwarerecs.stackexchange.com/questions/27546/a-c-nurbs-library-with-boolean-operations-that-is-not-opencascade

Did you discover anything else since then? Did you, by pure chance, had a look at the NURBS support in brlcad? They mention some mixed nurbs/srep support, but I never had the time to investigate if there is some code we could make use of, or if it's just CSG behind the scenes.

Did you discover anything else since then?

No. I'm pretty sure nothing OSS besides OpenCASCADE exists, at this point.

Did you, by pure chance, had a look at the NURBS support in brlcad?

Yes. It wasn't useful. I don't remember exactly why; you might want to give it a second look.

OCC is only marginally more complete, but even more geometrically unstable than solvespace. cadquery would be incredibly powerful if I could do any actual solid using it.

Yeah, the OSS NURBS situation is a disgrace. I wish I could use SDFs, this would solve so many problems... but the cost of killing STEP makes it a nonstarter.

I'm not sure it would be such a deal breaker. I've been using CSG a lot using OpenSCAD because it's incredibly robust, and I actually don't mind [too much **] working with triangle meshes when importing/exporting. Sure, it's crap for anything "professional", but for basic home milling and 3d-printing it's fine. In fact, I'm much more limited by the editors when making something from scratch then the requirement of reading external files.

There is such a huge gap between OCC and any other kernel, that just having some STEP support doesn't make a difference in my mind.

[**] I will still shed tears though

Two issues here. First, OCC, however flawed, has operations that are hard to implement in SolveSpace, such as chamfer and fillet.

Second, I'm not talking about STEP import. That's an entirely separate issue; it's not even clear that high-quality STEP import for SolveSpace is possible (though I'm leaning to "yes"). I'm talking about STEP export.

I'm personally not very interested in 3d printing and home milling. What I am interested in is contracting out fabrication of things like vacuum chambers, fittings, flanges and feedthroughs, and if you try that you'll quickly discover that machine shops want STEP. I mean, with enough time and money you'll find someone who will take a sketch on a napkin, but if you want it done quickly it's STEP.

Not arguing with this, I agree. Just to explain my line of thinking: for anything more than a hobby/small project I currently revert to commercial software.

At least, I wasn't able to find anyone with a set of skills even remotely approaching what's required to make the NURBS boolean code robust.

Don't talk in this way. Actually, I can do this. But I can't find a reason and inspiration to start the fight.

Don't talk in this way. Actually, I can do this.

Oh, sorry. I thought you didn't specialize in NURBS, looks like I misremembered.

What about following temporary workaround: force triangle for such surfaces automatically and display a warning that this is a known bug and will hopefully be fixed at some point?
Otherwise it is pretty confusing.

Not a fan of automatic mesh geometry. I expect solids to either work, or simply break like the current behavior.

This file is a simplified test case.
issue_315.zip

For whomever may look into this. I've found a hint. The file I attached in the previous comment does not exhibit the problem if you replace the curve in the sketch (that gets revolved) with a straight line. In fact if you delete that curve and create a new Bezier connecting the same end points and leave it a straight line (don't move the control points from where they get created) then the problem will return. In other words, a line revolved to form a conic works, but a straight bezier forming the same geometry does not. This suggests the problem is dependent on the degree/order of the surface. I know there is code to handle special cases (lines perpendicular to lathe axis are identified as flat surfaces) but not sure if any of those cases are in play here. If so, it points to a possible location of the bug. Another possibility is an issue specific to higher order surfaces (derivative calculations or similar). Just wanted to share this observation.