Understanding G64 behavior

I'm using the generic LinuxCNC postprocessor provided in Fusion 360 and encountered some corners getting rounded pretty severely - but inconsistently:

White being the path in the g-code, red the as-run path the machine took.  Some quick searching revealed that apparently G64 (path blending) with no tolerance is the default, which would allow it to round the corners like that.  Sure enough, I added a to the preamble (leaving the g-code otherwise unchanged) and it no longer rounded the corners:
 
Seems surprising that the default setting would allow such egregious deviations from the programmed toolpath, but at least there's an explanation - I guess I just need to edit a G64 P<> into the postprocessor going forward.  

It still bothers me though that I don't completely understand the behavior I was seeing with the default setting - why did it only round off the corners on the outermost loop of this pocket operation, while it did pretty square corners for all the inner loops?  In the subsequent operation (not included in this example g-code) I did a simple 2D contour to finish the inside of the pocket using a smaller diameter tool, and THAT operation followed the path closely, without rounding the corners, even with the default G64 setting
I'm running at about 0.25G acceleration (100 in/s^2) on my machine, and both operations were at similar feeds (~150-180 ipm) so I don't think this was a case of being acceleration-limited - the machine is easily hitting the full programmed feed rate on each of the straight-line segments.

Looking closer at the G-code, the one apparent difference between the inner loops and the outer one is that all the inner ones have straight-line G1 segments with very short G3 arcs in the corners, whereas the outer loop is exclusively G1 moves (i.e. perfectly sharp corners).  So, a plausible explanation might be that G64 with no tolerance will happily round off sharp corners at the intersection of straight-line moves, but when there's even a microscopic little arc in the corner it follows the corner very closely(?)

Any insight appreciated - just looking to make sure I understand what's really happening before blindly adding a "fix".

When you program a corner in G Code, the trajectory planner can do several things, all of which are right in some cases: it can decelerate to a stop exactly at the coordinates of the corner, and then accelerate in the new direction. It can also do what is called blending, which is to keep the feed rate up while going through the corner, making it necessary to round the corner off in order to obey machine constraints. You can see that there is a trade off here: you can slow down to get better path following, or keep the speed up and have worse path following. Depending on the particular cut, the material, the tooling, etc., the programmer may want to compromise differently.Rapid moves also obey the current trajectory control. With moves long enough to reach maximum velocity on a machine with low acceleration and no path tolerance specified, you can get a fairly round corner.

I most always use G64 P.001 ,  but this will cause to slow down at corners so it will stay within .001 of the path.

ref.1.2 Trajectory Control

Makes sense, but the main thing that surprised me is how a sharp corner is treated completely different than a corner with an extremely small arc joining the two straight segments (looks like 0.0128" radius in this case) even though to the naked eye those are very close to the same path - it behaves almost as if it's in exact-stop mode for the corners with arcs, even as it dramatically rounds off the square corners.
It's as though the trajectory planner is only looking one move ahead, because it seems like if it were looking further ahead then it should treat the two types of corners more or less the same.  Just curious how it works under the hood.

I think (might be wrong) that the planner is obliged to at least _touch_ each segment. So if there is a small arc then it will slow down enough to touch it.

The main driver for all this is the joint acceleration limits. You only really see these gross deviations when the speed is high relative to the acceleration. Did you guess your accel limits, or are they based on what the machine is capable of?

I'm running clearpath servos so I know they're faithfully obeying the commanded motion with no more than a trivial amount of positional error at any point; I've also tested them in-situ to 1G (386 in/s^2) before, so I know that the current acceleration limits are just a fraction of what the machine can handle. My back-of-the envelope math says 100 in/s^2 should be able to pull a much tighter corner than the >0.25" radius it did, but the magnitude of the radius isn't really my concern.

If the planner is in fact obliged to touch each segment as you suspect, then that would seem to explain what I saw.

What type of system are the clear paths running on? I have servos that can't run half that acceleration on linear rails and perfect ballscrews. The napkin is very different then what they deliver once you introduce inertia to them. Just because they are closed loop in their driver doesn't mean they are keeping up with the commanded speeds from Linux CNC. If I remember they only report when they don't complete steps, not if they are keeping up.

Could be way wrong