The first suggestion would seem nice and general, so good as a future solution. If it fits into the proposed scheme, then the ability to add an indefinite number of rotations would be even better. For example, do a pan, then a roll, then a tilt, and then do another roll. This arises often when one does a correction for tilted cameras say, and the one applies the navigational rotations. For example in my command line apps I can do
-x 20 -y 90 -z 5 -y 20 etc
The second suggestion for this particular node would cover most cases (not all though) since panning and then tilting within 360 camera footage is the most common navigation, simulating longitude and latitude navigation.
Hmmm, the formula by which the MousePosition coordinate is transformed is (v+1)width/2 where v is the input to the MousePosition.
One kind of needs to understand this to supply the reverse if one wants to use a known coordinate system within the shader.
Can I suggest the make shadertoy documentation is amended to include a statement to the effect that the mouse position input is scaled by the width (or is it 1/2 the width?) to give the iMouse variables ... not necessarily obvious and tricky to track down since it is done behind ones back. The mouse position input is in Vuo coordinates and iMouse is pixel coordinates, just one (at least me) is not necessary expecting some scaling of node inputs.
