@timhoffm:
The PR#29244 proposes a trick to fix a perceived deficiency of thetrackball mouse rotation style: the dependence of the orientation on the details of path the mouse took, even when the start and end of the mouse motion were identical.

The proposed PR might seem to fix the 'path dependence', but unfortunately, it is only a superficial fix - it has unintended consequences: if you would momentarily released the mouse button during a mouse drag, then the outcome in general will be different - even when the path taken was exactly the same.
None of the other methods suffer from this. For all the other styles, the rotation is purely incremental. (The particular location of the 'touch down' is not relevant later on, only the mouse motion is.)
Thus the proposed 'improvement' comes at a price, and the cure may be worse than the disease.

Moreover:

• The proposed modifiedtrackball style no longer has a straightforward physical interpretation, like the originaltrackball style, in terms of a ball covered by a plate that you drag with the mouse; this is a loss.
• The documentation (even though it would be updated) still suggests that it does, erroneously.

The proposed modified mouse rotation style is altogether different from thetrackball style, arguably it is closer to theazel style in spirit.
Hence it should not supplant the trackball style; it could be an additional style, at best.

The proposed new style drags along twice as much 'state': not only the quaternionq for the current orientation (like all the other mouse rotation styles), but also_q0, for the orientation when the mouse button was initially depressed.
Not pretty.
Worse, the implementation is brittle: if you'd switch to the new 'trackball' mouse rotation style while the mouse button is already depressed, then when you move the mouse pointer, the on_mouse_move() call will error out since _q0 is not defined...

To be honest, I do not quite understand the preoccupation with the 'path-dependence'. It is a natural consequence of the plate-on-a-ball arrangement of the trackball mouse rotation style; and the path-dependence is actually useful there, since it provides a way to conveniently adjust roll (by moving the mouse in circles), which is needed for this style, since, unlike thearcball, it does not have special a provision for it. That is to say, the path-dependence is a feature, not a bug, for the trackball.
(The proposed changes to the documentation removes this hint, also not an improvement...)
With the PR, it becomes impossible to adjust the roll in one mouse drag. Not good.

In summary:

• I don't think this PR is a good idea, let alone ready for 3.10;
• I would certainly not advise it for the default style - it makes it hard to control roll.

I think we disagree on which properties are features vs bugs, and the remaining objections can be fixed with docs tweaks. But if there's not clear agreement then I'll close this PR and we can wait for user feedback.