htmx:responseError and hx-sync queue behavior for shared swap target

Designing consistent client-side coordination for components that share a single swap target under concurrent triggers. The goal is to define predictable latency and error surface when multiple source elements can initiate requests to the same DOM node.

Relevant constraints are documented htmx request coordination via hx-sync with modes such as parallel, abort, replace and queue. The default sync behavior is parallel, with no built-in response versioning or ordering guarantees. Error conditions surface as DOM events like htmx:responseError and htmx:sendError rather than thrown exceptions, and processing is not halted by the library.

There is an unresolved design decision about a canonical policy for aborting in-flight requests when a new trigger from a different source element targets the same node. Developers must choose hx-sync values per element, which can lead to inconsistent UX across pages, especially when queue mode intentionally serializes requests and creates observable latency under concurrency.

What is the intended interaction between hx-sync queue on a shared target and htmx:responseError emission for individual triggers? Should an error event from one source reset or preserve the queue state for other sources targeting the same node? Is there a recommended default for cross-source abort behavior when no explicit hx-sync is set on the new trigger?