Given two quaternions representing two orientations, there is a representation of the difference as a single rotation angle about a single axis. So, the most common implementation is to attempt such an "eigenaxis" rotation. From rest to rest, this is always possible, but if you are already rotating it's not always easy. Adding a constraint (such as I want to rotate but keep one side facing the nadir/"down" direction) is beyond the scope of what KSP is going for, I think. It can be done, but is more difficult to do smoothly in a closed-loop simulation that only depends on the current vehicle state.
The tricker part here is how you represent either the current vehicle quaternion or the target direction. Saying "I want to point in the prograde direction" is not proscribing an orientation, because it leaves the roll angle about the pointing axis undetermined. So, there are an infinite number of quaternions representing this direction. Picking which one to plug into the Unity helper function is a non-trivial task and may or may not matter. Sometimes, you go "whatever, I don't care" and make a random selection, or hold some other value constant. And sometimes, that breaks the behavior in odd ways. I was suggesting that was one possible cause.
For an aircraft, Euler angles provide a natural way of representing pitch/roll/yaw from a reference case. Some quaternion implementations start with this and then convert to quaternions for the "under the hood" calcs (example in Unity). But, this destroys one of the benefits of a native quaternion representation, which is avoiding singularities that are present in Euler angle descriptions.
This statement is entirely true, but I doubt that is what the KSP2 simulation is doing, or at least not in detail. More likely, it is a simple feedback law saturated by available torque. I don't even know for sure if there is an allocation strategy (for example if I have multiple SAS modules) or if the parts are just additive to some vehicle maximum torque. The latter is simpler and faster, but less real world. The former introduces a new spot for error, because most allocation methods have singularities. I'm guessing it is somewhat of the former, with the torques added as part properties, because of the attitude instability of long, slender vehicles.
In terms of "maybe it makes more sense", one possibility is to estimate this by computing maximum torques and time in both directions, but doing so and including saturation of the torque elements is computationally expensive. So, you would have to have decent estimating procedures. Otherwise, it is generally an optimal control problem (which I love, but is probably beyond the scope of real-time simulation).
