The "why" was to simplify the user interface.
From a user perspective, if I were to pickup a RC control for the first time today, I wouldn't be burdened by heritage of how things used to be controlled or why. As a user I'd be interested in making the aircraft move as I would desire in a intuitive and easy to understand way. I'm not saying this way is the best, only that I would like to see a RC control method that can accommodate various platforms, especially the emerging ones, that don't yet have dedicated control methods.
There's enough dimensions on the RC sticks to achieve that. This is not a "flight control system" as so much a "user input" profile. In the end the user doesn't care if it changes course because of yaw induced roll, or aileron bank and yank (either of which effect altitude and throttle to maintain airspeed as well). The idea was to improve the user experience, not to create unnecessary or complicated RC modes.
Ideally the user interface would be something that they can operate to create the desired effect with nearly no knowledge of the platform, apart from that quad motors make it hover when it's slow, and wings make enough lift in forward flight. I think as a "emerging technology" there's an opportunity to make a standardised interface that newcomers can learn, without having to jump through the hurdles of learning the old ones. A classic example would be to use the 6 DoF 3D connexion type controller as a user interface, but I think for field use there should be a better way to us the RC sticks for control as well. Most BT/wifi joysticks, come with centered throttle sticks as well, and the Parrot Disco uses the same type of throttle control in flight.
As for the vehicle type I think any vehicle could be controlled in this type of method. But VTOLs, like QP or tail/belly sitters would benefit most. There's also an opportunity to add some airspeed specific behaviour in this type of control. For example if in fwd flight the aircraft could use reverse thrust to slow down, or use the forward motor for forward and reverse flight in hover.
Being a "Auto mode" the aircraft flight state (like forward/hover) should only change if the user's commands to do so regardless of the aircraft conditions. This would mean that a gust of air or crosswind should not affect the user's intended flight path or command. In this case the QP aircraft at 500m would not change from it's current flight mode (hover or forward) and airspeed would dictate what it's current flight mode is. Should it be in forward flight mode it would maintain forward flight by ensuring the minimum forward flight airspeed is kept even when the pitch stick is centered.
Yes. So velocity in hover and attitude in forward winged flight.
It should really be yaw rate with course lock not a compass heading lock. The user is largely oblivious to the flight conditions of the aircraft, and is navigating visually from the earth frame, so from the user's perspective it's important that the aircraft proceed along the desired course regardless of if the aircraft is being blown of course by a crosswind etc. which requires the heading to be adjusted.
I hope what I've written makes sense.
(And sorry Greg for taking up the build thread space!)