InputMultiplexer consumption limits when Stage and custom processors compete

The short answer

An event is consumed the moment any processor in the chain returns true from its handler, and dispatch stops immediately — processors registered later never see it. A Stage actor listener consumes an event only when three conditions hold: the actor is hit at the event's screen coordinates (Stage.hit() finds it), the actor is visible and touchable, and its listener returns true. Registration order in the InputMultiplexer is the entire precedence system: whichever processor is added first gets first refusal of every event.

What is confirmed behavior

• InputMultiplexer iterates its processors in insertion order for each event. The first true return aborts the loop for that event.
• Stage is itself an InputProcessor. Its touchDown/touchUp etc. forward to actors under the pointer. If an actor's InputListener returns true, the Stage's handler returns true, so the multiplexer treats it as consumed.
• Actors that are invisible, Touchable.disabled, or outside the hit point do not consume anything, and the Stage then returns false, letting the event continue down the chain.
• The stop-on-true rule is consistent across LWJGL, Android, and GWT backends. What varies per backend is event timing, touch coalescing, and pointer semantics — not the consumption contract.

What is likely, but verify in your project

Backend queue differences do not change whether an event is consumed, but they can change which events exist in a frame. Android may coalesce rapid move events; desktop delivers mouse and keyboard events that have no touch equivalent. If your custom processor polls Gdx.input continuously in render(), that polling is independent of the multiplexer entirely — consumption only affects dispatched callbacks, not polled state. Apparent "consumption failures" are very often coordinate bugs: Stage and multiplexer callbacks deliver screen-space Y-down coordinates, and forgetting camera.unproject() (or unprojecting with the wrong viewport) makes world-space hit tests miss, which looks exactly like an actor swallowing events.

Diagnosing your specific setup

1. Log entry and return value in each processor's handler, plus a listener log in the suspect actor. One frame of output shows the exact dispatch order and who returned true.
2. Swap the registration order — multiplexer.addProcessor(stage) before vs. after your custom processor — and confirm delivery changes. If it doesn't, something else (often a GestureDetector wrapping a processor) is in the chain.
3. Call stage.hit(Gdx.input.getX(), Gdx.input.getY(), true) at the moment of the event and compare with the actor you expect. A null or unexpected result points to unprojection or touchable-bounds problems, not multiplexer ordering.

// UI gets first refusal; game logic sees only what actors reject
InputMultiplexer mux = new InputMultiplexer();
mux.addProcessor(stage);        // actor listeners consume first
mux.addProcessor(gameInput);    // receives only unconsumed events
Gdx.input.setInputProcessor(mux);

The one detail that would change this recommendation: whether your custom processor needs events even when the UI consumes them. If so, don't rely on order — have the actor listener return false after handling, or forward the event manually, since the multiplexer has no "observe without consuming" mode.