At the risk of sounding callous, you are speaking for yourself and not necessarily “the bulk of” users.
I chose ArduPilot specifically for its high degree of compatibility and flexibility at the known expense of simplicity. While my use case seems simple at face value, autonomous lawnmowing, it’s actually full of complex problems: path/coverage planning, GPS precision/accuracy, compass/heading issues complicated by whirling iron parts, etc. I’ve been HIGHLY encouraged, particularly recently, with the development team’s progress, receptiveness to feedback, and often very fast response time to incorporate fixes or features.
I do sympathize that simple waypoint navigation seems unnecessarily complex at times, but that, again, is a result of the intentional flexibility built into the software. For highly configurable flight controllers in a 6DOF flight environment, a rate controller like ArduPilot makes a ton of sense. For land navigation, that same rate controller can be somewhat difficult to tune properly for direct-to-fix navigation.
As such, I see your request for “simpler” control as a request for more complexity. I think at the root of it, you are asking for a heading controller as opposed to a turn rate controller, which would entail MORE parameters, and likely an additional library for inclusion to the code base.
The next few iterations of the firmware may address this in a slightly different way than changing the feedback controllers, though, and I look forward to it. @rmackay9 is working hard on incorporating S-Curve navigation into the Rover branch which may indeed help Rover-4.1.x or 4.2.x function more like you (and I) prefer.
I’ve noticed the dev team is highly attuned to the complexity of the parameter list and quite hesitant to include more of them. There are some great discussions in the GitHub issues and development topics where you can see their concern for adding complexity and, likewise, their desire for keeping the user experience as straightforward as possible.