A few years ago I decided to fix my biggest gripe with Unity's InputSystem: there is no intuitive and fuss-free way of determining which UI, character controller, popup, etc. should be receiving inputs at any given time.
Sure, the Action Maps are a great baseline for handling this since they let you assign a set of inputs to each given system; but you still have to make sure to enable and disable them at the correct moment. This can be easy in a small project, but when you have dozens of systems and UIs to contend with; it can get kind of messy.

So I started working on a system that sort of "automatically" handles all the mess for me and handles the complexity on its own.
After a few years of working on it when I felt like it in my spare time, I'm officially taking InputLayers out of beta:

You can get InputLayers for free on the asset store.

What is InputLayers?

The short version is that it's a system that lets you assign input actions to layers that "stack" priority. So when your popup comes up on screen, its layer is added to the top of the stack; and as long as no other layer takes its place, only inputs from that layer will be taken into account.
There's a bit more depth to all this, with layer priorities that prevent less "important" systems from taking over higher priority ones; but at its core; it basically lets you set things up using a single configuration window; and then never have to worry about if your character will keep moving when your main menu is open, or whatever other similar conflict you can imagine.

Video overview

I go over the core idea in a little bit more detail in this video: https://youtube.com/watch?v=bXEuzpbGlCI

Sample scenes

I've included a few sample scenes that cover most of the basic use cases. Their code is a bit complex if you're unfamiliar with UI Toolkit, but I've mostly isolated the fussy stuff so you can concentrate on understanding how the actual InputLayers stuff get handled.

Documentation

I've set up the documentation over on GitHub for ease of access; and so that people can post issues they may encounter easily.

This is really amazing, in my opinion Unity's InputSystem is servicible but not mind blowing. My pain points would always arise with menus when returning to a scene, especially when I was in school. They should bundle your tool as a permanent part of Unity honestly this is awesome. Unfortunately I am all in on Godot but I'll pass this to my friends who still use Unity!

Thanks!!

TBH, I'm probably going to switch over to Godot at some point myself as well.

Cant recommend it enough. Its amazing.

I hate how Godot has an array of mapped buttons to a specific action, but denies you direct access to change them in the order they're in. This is problematic if your game has the main keybind + secondary + controller for the same action and you want to let players rebind them all.

It could also use something like that layeredInput, since it can be a bit of a juggle to ensure that 2 open windows don't close if you press input.CANCEL, instead of only the focused one.

Not sure if I'll ever get around to adapting the concept to Godot, but I'd be happy if anyone comes around and takes the core logic that's there and adapts it ;)

Without actually looking at your code, the first thing that came to mind is making something akin to the Collision masks that nearly every node has, where you just set a value and, during the game's runtime, input processing checks every node that has the same value - for instance, if opening a menu set the InputLayer to 2, only nodes that are of value 2 will process, every other will ignore. So, one extra variable and one extra check before processing any input

I went with a stack pattern and priorities.

Within a priority the last "layer" to activate is the only one to receive inputs. The priority system just means that if a layer from a lower priority gets activated, it doesn't take over until the upper layer is empty.

It's a bit stricter (only one layer active at all times), but you can always subscribe to inputs from multiple layers to achieve what you were describing.

The main advantage here was that you can safely rely on enabling/disabling layers without ever getting a conflict... If some popup comes in over your menu, the popup is in charge until it's closed. No need for them to communicate, and you reliably know that inputs will eventually return to the menu properly, even if something else gets interposed.

And since it's tacked onto the existing system, you can always have parts of the code that ignore the layer system entirely if necessary (like a mute button that has to work across all systems/menus for example).