Isn't it weird that _is_nav_modifier_pressed returns true if a shortcut is undefined? That sounds like a recipe for issues such as this one, it's counterintuitive with regard to the name of the helper method.

Isn't it weird that _is_nav_modifier_pressed returns true if a shortcut is undefined?

I agree, although the reasoning for it, is somewhat explained in the OP of #85331:

I wanted to use just one modifier for each operation, but due to a bug (or intended behavior?) in InputEventKey modifiers, pressing a modifier with it's "main" key and then releasing the modifier will still count the button as being pressed. This Reddit post explains it best I think. Another benefit of 2 modifiers is being able to set 2 different "standard" keys like Z/X as opposed to being limited to CTRL, ALT, etc.

As long as two slot system is used, if one is undefined, that one needs to act as pressed if the other one is pressed. It seems like possibly that whole system is due for a review. Given that it was intentional, changing it at this point would probably a breaking change until how shortcuts are handled in general is reworked to handle these scenarios.

It seems like possibly that whole system is due for a review.

For example: #115776

I'll probably take a look at it more in-depth at some point, but this PR should be fine to resolve the regression.

Also worth noting, we're apparently lacking feature parity between the editor viewport and the runtime debugger / game window when it comes to navigation mode preferences. I believe @YeldhamDev intends to refactor things to be able to reuse that logic in both, but I agree that some de-spaghettifying of the navigation/modifiers code could be worth doing first.

Thanks!

Cherry-picked for 4.6.1.