htmx swap silently does nothing when the target element is removed before the response arrives

I am building a page where an htmx request targets a container that can be re-rendered by a separate part of the UI while the request is still in flight. The button uses hx-get with hx-target pointing at that container and hx-swap="innerHTML". When the container is replaced in the DOM before the response returns, the update appears to vanish: no visible change, and no error surfaced in the console.

My understanding is that htmx resolves the target at request time, and if that node is detached before the swap runs, the mutation is applied to a detached element and effectively lost. I also see references to rapid sequential requests against the same target producing last-response-wins behavior, which may overlap with what I am seeing when the container is re-created between requests.

Assume htmx 1.9.x loaded from the official CDN, standard browser behavior, and a server returning a plain HTML fragment with a 200 status.

Is the silent no-op when the target is detached the documented, expected behavior, or should htmx report it somewhere? Does re-resolving the selector at swap time versus request time change anything here? And what is the intended pattern for guaranteeing a swap lands when the target region can be re-rendered concurrently?