Thanks for suggesting a likely cause. VCarve is a bit weird in that it’s not a pure-geometry program in calculating its toolpaths. 3D models are converted into grayscale heightfield image maps which are then used to calculate the toolpaths. So resolution of the image map determines how accurate the toolpath is. There are Standard, High, Very High, Extreme, and Maximum model/image resolution settings. The Maximum resolution setting was used for my files; but of course, while being most accurate, it also generates the smallest line segments. That could cause the issues you are talking about.
After your post, I found the 2D/ 3D/ Vcarve toolpath tolerance settings in the Options menu. Like the Avid video here: Z Movement loosing steps, reproducable any height, with this code - #11 by Stephen , the VCarve default settings were 0.0004".
While they can be tolerance-reduced, Vectric told me that 3D toolpaths cannot normally be “smoothed” into efficient arcs (rather than polylines) as in Fusion’s setting because 3D toolpaths generally are not XY arcs but move in all three directions.
I made a tiny toolpath area and gcodes for the Standard, Very High, and Maximum resolution settings, with the default 0.0004" tolerance. The gcode file sizes were 15kB, 22kB, 27kB.
After I changed the tolerances to 0.001" I resaved the test toolpaths. The Very High decreased to 16kB (barely over the Standard default), the Maximum decreased to 20kB (smaller than the Very High default).
Unfortunately, I do not know how to re-import gcodes back into Rhino so I can look closely at the tolerance-reduced versions vs the default versions to see which is smoother or has fewer tiny segments. The files are attached. My hunch is that the issue might not be the U-turn at all, nor the drop (perhaps) but maybe the round-over from the plateau into the drop.
