htmx Request Lifecycle and hx-indicator/hx-swap Under Load

Assuming htmx 2.x, the goal is to define an integration contract between htmx’s request lifecycle and hx-indicator/hx-swap behavior when a user action can start overlapping requests. The contract must distinguish request in-flight state from DOM update state because the indicator’s CSS class and the target’s replacement follow different lifecycle boundaries.

The unresolved issue is whether concurrency represents multiple independent request lifecycles or one logical operation. With hx-swap="outerHTML", a later response can replace content produced by an earlier response; with hx-swap="innerHTML", the target structure remains while its children change. The expected indicator state when responses finish out of order also needs definition.

Should hx-indicator remain active until every overlapping request for that target has settled, or track only the latest request? Should late outerHTML responses overwrite earlier updates, or should ordering be enforced at the integration boundary? Which htmx lifecycle event or DOM condition should be authoritative for completion?