InputMultiplexer consumption limits when Stage and custom processors compete

When a Scene2D Stage is registered in an InputMultiplexer alongside a custom InputProcessor, the precise point at which event consumption occurs and how it propagates to remaining processors depends on backend-specific event queue ordering. The documented behavior states that returning true from an InputProcessor consumes the event, preventing subsequent processors from receiving it, yet Stage actor listeners and multiplexer ordering interact in ways that are not uniformly specified across LWJGL, Android, and GWT backends. This creates ambiguity for games that rely on discrete UI input from Stage actors while simultaneously processing continuous polling from Gdx.input in the same render loop.

Constraints include variation in callback delivery timing and available event types per platform, as well as the silent starvation of downstream processors when an upstream actor or processor returns true. Additionally, touch and mouse coordinates are provided in screen space, requiring Camera.unproject for world-space comparisons, and incorrect unprojection can produce input logic errors that mimic consumption failures.

What exact conditions cause a Stage actor listener to consume an event and block subsequent InputMultiplexer processors? Does the relative registration order of the Stage and a custom processor determine which events are consumed first? How do backend-specific event queue implementations differentiate between actor-consumed events and processor-consumed events on desktop versus Android?