Randy, thank you so much for the quick response.
I disabled the arming checks WAY back when I was first testing GPS yaw because I wanted to be able to drive in manual if I accidentally achieved a completely useless navigation system. I guess I just left it that way. At this point I can probably re-enable a few common sense options here.
For skid steering, I’m using RC1 and RC2, such that all rover steering is controlled by the right stick on the transmitter (pitch and roll channels). SERVO1 and SERVO3 are actual heavy duty servos (not ESCs) connected to the hydrostatic control arms that one would normally push and pull to manually drive from the seat. Not only can I drive in reverse, but I can technically go faster in reverse due to a physical limitation of the servo linkage in the forward direction.
RC3 is completely unused and has no effect The actual engine throttle servo is SERVO4, mapped to RC10 and is independent of navigation, since it’s a hydrostatic system that relies on increased engine RPM predominantly for power rather than vehicle speed, though both are affected to some extent.
In fact, perhaps I should’ve used more engine RPM during this test to avoid the saturation you mentioned. I had the RPM lower than I typically use for mowing, and the mower was likely unable to achieve the desired speed at full SERVO1/3 forward throw. The mower can indeed achieve 1.5m/s (~3.5 mph) with no problem, but my test run was likely power (and thus speed) limited by the low engine RPM. I should’ve cranked it up to “normal” RPM for mowing to give you a good test case - which I can certainly do if you like. But maybe my low RPM error was serendipitous in revealing the I-term buildup error 
There is very little dead zone between forward and reverse. What little dead zone exists is actually physically present in the linkage between the servo horns and the steering arms, such that the trim values cause the servo position to fall in that physical dead zone with neutral RC transmitter stick, reliably stopping motion. If I understand correctly, accounting for that dead zone might cause snappier transitions between forward and reverse, but I’m uncertain that it’s desirable for this control scheme. I’ll explore it a bit.
EDIT: Now that I think about it, because it’s physically present and not an electronic feature, the “dead zone” manifests anytime the servo reverses direction, which could be anywhere in its throw range. With that in mind, I doubt there’s much to be gained by defining a dead zone around the neutral position…or else I have a conceptual misunderstanding of that parameter.
MOT_STR_THR_MIX is definitely one to check out. I’m excited to change it and discover the effects.
The NAVL1_PERIOD surprised me, too! I think in order to use a value that low, the rest of the tune has to be very precise, which I hope I’ve achieved, though you mentioned a noisy turn rate - I’ll investigate.
I arrived at that low NAVL1_PERIOD value very recently during my exploration of the BendyRuler algorithm for fence avoidance. I discovered that decreasing it caused a desirable aggressive turn back to the waypoint path once the fence was cleared, keeping the margin tight on the back side of the fence. I just kept decreasing it until I saw something I didn’t like (which happened at 1, where the oscillation was just too much).
