Hello!
I am not sure yet if it is a feature request or my misunderstanding of the intended usage of the dear imgui input system.

I am on version 1.70 WIP, docking branch - sorry, I failed to find answers in the FAQ/demowindow code, and neither I've seen similar things in the issues (although it somewhat relates to shortcuts API #456, but probably more broad). The problem I am looking at is using dear imgui in the complex input scenarios, including allowing windows (and child windows) to have their own hotkeys and allowing keyboard navigation and whatnot. But the problem I've encountered is that imgui only provides WantCaptureKeyboard without specifying which inputs did it process.

To illustrate the usage scenario: there is a window with background global hotkeys (for example, WASD for camera, or some other state switches if viewport is in a subwindow), and there are children windows which are more like "subspaces" - i.e. each have associated logic which have the associated set of hotkeys (for example when Subwindow1 is active, hotkey N shows debug normals; and when Subwindow2 is active, M spawns mesh, and N does nothing, or something other from when Subwindow1 is active). Theoretically this also can have multiple nested levels. These subwindows naturally can contain elements like input boxes, checkboxes and other elements which may be modified or navigated between using keyboard too.

Couple of straightforward ways of doing this that I can see would be a) prioritized input events subscription queue, which can consume input events if required (and block further propagation), and build this queue based on the activity of the elements - this effectively means running imgui first to fill the state or one frame lag; and b) polling the event queue when drawing elements to see if the element was active this frame and consuming/rerouting the input to the next frame - necessarily frame lag, and possible problems with the io internal buffers flushing and guarding from events going to another element - unless adding function to determine whether the element to be drawn is active is not considered a bad practice.
The way b is more imgui-friendly, but both approaches seem to share common set of problems.

What's more important, there is no way to tell which input exactly was consumed by the imgui, which can matter in cases with input box (wants to consume any alphanumeric and some more) vs check box (wants to consume spacebar/enter to change state) - or if that was simple navigational event (some subwindows/containers may block navigational events to use hotkeys for their own purpose - but that can probably be achieved using io.NavActive to some extent).

Thus my question is what is recommended in cases like that when using dear imgui, and maybe if that's not what currently easily achievable, we need to devise a minimum set of features (requests) required to implement this.

Thank you!

Edit: added comment about active ids.