Yeah, makes sense. Also not sure how to name it though :)

Why name it? Couldn't this be automatic? I don't understand why can't the axis for movements always be relative to the direction the screen is facing, or a default option for that at least (i suppose some games might have weird required movements that move the screen to something not facing the player).

edit: ok, if the tilt would change the facing direction (ie, not like a steering wheel) it would be functionally the same as a non-op if it was 'always updating', but there may be a solution to that with thresholds.

Added a third option (auto-switch) that change mode if it detect a big change in orientation, it seem to work fine on my phone, also having a multi-choice seem better at explaining what the setting does.

Fix #10515

Anything else you want to squeeze in here? I'm inclined to just go ahead and merge this, it's useful functionality.

The button masking is not perfect: it allow you to press a button controlled by tilt with touch as well, but it can be released by tilt even if it was pressed with touch in first place.
To handle all the possibility we will need some more masking variable, but i am not sure if is really worth the extra code complexity for such a corner case.

That the only thing i think it's left in case is needed.

EDIT:
CtlrPeekBtn might be enough to do the trick, i will test later this evening.

Now it will not reset a button that was held when the tilt enable and then disable it.

If a button get pressed when it was also enabled by tilt, tilting back will release it even if the button is still hold on touch screen.
I don't think this can be worked around easily with the current data struct (I might be very wrong on this tho'). I am not sure if is worth making thing more complex for such a case as well. Any suggestion is welcome ofc.

That's the last part that itches me, if you think is not worth going around that you may just go ahead and merge.