Floating point numbers are not closed under addition. They are not real numbers and not rational numbers. FP is on a grid whose size changes the farther you get from 0,0. For example 0.1 doesnt exist in fp nor does any number not representable by binary fractions. Also its a quirk of opengl and most 3d renderer to get issues when one surface coincides with another so the preview renderers like the little bumps. Also the underlying CGAL rendering kernel can be problematic when planes are almost nearly coincident but not one hundred percent. Finally OpenSCAD has an internal grid it tries to snap things to which can also cause issues. Not sure if the new Manifold renderer has these issues but in general the loss of info from ascii decimal to FP is the source of most of the problem. Those professional cad programs have enormous resources behind the scenes to make that stuff appear easy when its actually very complex and basically an illusion. Rotating anything using sine and cosine instantly loses information so planes with more than three points become non planar ever so slightly. So this assembly you made with “two surfaces touching” is not touching after rotation due to sin eing transcendental function simulated on a computer with finite time and memory. For example. These fancy CAD systems all have ways to deal with this.

Thanks for explaining that; that makes sense.

I still don't /like/ it because it seems I'll need to add in some sort of 0.001mm overlap into the code if I want to ensure this doesn't become a problem. And this feels like a messy way to go about it.