> don't know if the author has a specific example in mind, but if a user submits an input, changes that input mid-request and submits again the request needs to be cancelled, otherwise the UI will be inconsistent by showing a response to an outdated input
If you queue them and process responses in order, that would also be correct. Probably has fewer failure modes. Some indicator that an element is still being processed would help to prevent user confusion though.
if a response is meant to swap out a div, the first response completing will swap it out - if this response isnt compatible with the same selector (e.g. a #response is not available) a second completing response won't be able to update the UI
There are many choices here, such as never setting outerHTML but only innerHTML/nested content. Also, "processing responses in order" doesn't necessarily mean "immediately mutate DOM for each response", eg. defer if there are in-flight requests and aggregate changes. htmx arguably gives you too much flexibility which is why there are no straight answers that work for all scenarios.
If you queue them and process responses in order, that would also be correct. Probably has fewer failure modes. Some indicator that an element is still being processed would help to prevent user confusion though.