This is interesting, it looks like a coincident surfaces or edges issue. Not only does save/reload make it go away, but weather if fails or not depends on the length of the last extrusion. It's failing in raycast.cpp just below the section of code with this comment:

//! @todo make this use the appropriate curved normals

What does that mean? I've read this before and don't understand the comment, maybe because I don't fully understand what it's trying to do yet.

Another test case:
if draw figure with line from 2 segments on edge, then after extruding all figures on edge will incorrect

wrong2.zip

This seems fixed? The problem is I could not reproduce it even on (e.g.) 70ec7cc from may.
@phkahler how about you?

@ruevs No it's not fixed. Just shorten the larger diameter extrusion and the red will appear. The example in "wrong2.zip" does get fixed by PR #737, so I'll use it as a regression test if I decide to implement that one differently. Good catch!

Oh I had your

                if(vm < 0) { // happens when we revolve with negative theta
                    of = of.Minus(v);
                    v  = v.ScaledBy(-1);
                }

in my tree an thought that was the reason. So I removed it and I still can not make it fail (wrong.zip) - shortening the last extrusion, deleting it an re-creating it - it works?!

another test case (3.0~bcb8cd2c)

wrong3.zip

@starsolaris What OS are you using? I don't have any problems wrong3 on Fedora Linux. I even asked it to show naked edges and none were found.

@phkahler Windows 10 20H2 (19042.630)

I can reproduce it as well (Windows 10) on 3.0.rc1 and my own master compile.

Can either of you try a 64bit windows build? That should not be the fix, but if it works that could be a clue.

@starsolaris I noticed that group g004 in the file wrong3 has one degree of freedom. I then found the following point can still be moved:

It was visually on top of the corner point until I dragged it, but having points unconstrained when you want them coincident isn't really a great thing. Either make the 2 long lines in g004 eQual length, or delete the H constraint on that line and constrain the points coincident (select both and press O) - you only have 1 DoF left for that point, so you can't just make the points coincident without removing the H. See if this helps the problem with the later extrusion.

@phkahler this is not help with the later extrusion

wrong4.zip

@phkahler Ha! On one of my machines with MSVC 2019:

The exact same source (942bf3f) on the same machine with the same compiler version! WTF!?!?!

My "favorite" type of problem...

x86 uses the old x87 floating point unit where x64 mandates SSE2 and disallows x87. Contrary to what some people think, the fact that IEEE754 is a standard does not mean all floating.point operations produce the same result on different hardware. x87 uses 80 bits of precision internally for example. I suspect the issue here may be a comparison for exact equality somewhere that maybe should use an epsilon,, or something like that. Or maybe it's related to my changes in removing short segments, but I doubt that's it. It could be anywhere.

What about the x86 "Release" target working? Probably compiler optimizes floating point math to SSE2 (64 bit floating point)...

In fact there was a lengthy discussion on 80bit vs. 64 bit doubles back in March #565 and at the time Whitequark forced SSE2 on GCC and Clang in 645353c .

My 32 bit (x86) Clang 11 (release) build on Windows works :-)