I'm not an expert in this topic, so do we really need all those impementations? I assume 99% of users just want that "it works", which means one good rotation style should be enough.

I'm not an expert in this topic, so do we really need all those imp[l]ementations? I assume 99% of users just want that "it works", which means one good rotation style should be enough.

I was originally of this opinion too - see #28290 (comment).
But I can see Scott's point; and there are legitimate trade-offs between various mouse rotation styles. With a few lines extra code we could accommodate the various preferences.
As for the 99% of users, they will have the default style and it will "just work" for them.

this variation spoils a nice feature of the original Arcball (as Scott Shambaugh pointed out): if you move the mouse back the original point on the screen, this would return the view to the original view

This is the main thing I'm hoping to resolve, but I can see the different rotation modes being useful for different input devices / accessibility concerns.

This is the main thing I'm hoping to resolve, but I can see the different rotation modes being useful for different input devices / accessibility concerns.

I have a PR in the works for it, almost ready, but I'm waiting for the merge of PR #28395, I'd prefer to finish one PR before starting another...
Could you take a look at it, or ask someone else to do so?

I would go as far as to argue that rolling the axes in 3d is an anti-feature in most cases. The gain in flexibility makes it harder to control and achieve the desired view with mouse interactions. This is especially the case when viewing data that is plotted with z-direction being physically meaningful is some way (like a 3d histogram or wireframe with size in the z-direction measuring some quantity). From a visualisation perspective, rotating in azimuth is very useful here, while rolling is actually just annoying. Therefore I think it's essential that we are able to restore the old rotation behaviour on user request. I was envisioning something like holding down CNTRL key to toggle the rotation behaviour.

I would go as far as to argue that rolling the axes in 3d is an anti-feature in most cases. [...] Therefore I think it's essential that we are able to restore the old rotation behaviour on user request.

I take it that you are very happy with the change proposed in this Issue, then?

I was envisioning something like holding down CNTRL key to toggle the rotation behaviour.

This proposal I find puzzling - surely a CNTRL key does not mesh well with the 'principle of least surprise'? (And you want to hold it down? Or you want to toggle?)
Would a selection on the toolbar be better?

Could it be that what you really want is to constrain the roll to zero to keep the z axis parallel to the edge of the figure? That is a separate issue from having the rotation respond naturally to the mouse (i.e., move mouse to the left/right/up/down -> tilt figure to the left/right/up/down, consistently). Perhaps it deserves raising a separate Issue? (Feel free...)

Would a selection on the toolbar be better?

IMHO a rcParam for the rotation mode should be good enough (if we need multiple options). You can set this globally in your matplotlibrc, or you can set it before showing the figure. You'll hardly need to toggle different modes live.

This makes implementation much simpler.