I thought they were complaining that any request is being cancelled by a subsequent one, since they wanted all the requests they made to go through (presumably the requests are altering state?) Probably I misunderstood what was meant by “losing work” though.

>https://github.com/bigskysoftware/htmx/blob/1242977d11bebe56...

This seems to be a scenario where switch/case blocks could make the elif-trees a bit easier to read.

Also, the code could use some care about not going so deep into the Vs:

    // request headers
    if (requestAttrValues.noHeaders) {
    // ignore all headers
    } else {
      for (const header in headers) {
        if (headers.hasOwnProperty(header)) {
          const headerValue = headers[header]
          safelySetHeaderValue(xhr, header, headerValue)
        }
      }
    }

could just be:

    // request headers
    if (!requestAttrValues.noHeaders) {
      Object.keys(headers)
        .filter(hdr => headers.hasOwnProperty(hdr)) 
        .forEach(hdr => safelySetHeaderValue(xhr, hdr, headers[hdr]));
    }

Not even sure if that hasOwnProp check is needed, unless header keys are explicitly set to undef.

I had to read and think carefully enough about what you just explained (on second try!) to feel like I understood it, so I'm not at all surprised if other people are confused about or misinterpret what they are seeing! (I'm not an htmx user though).

Actually, I guess, then, OP just had an off-by-one error? Imagine requests [r0, r1, r2 ... rN], where r0 is still in flight... OP thought r0..r(n-1) would be cancelled, in fact just r1..r(n-1) will be cancelled (I think?). Or maybe OP understood it but just mis-described it!

I am curious to hear the reasoning/use cases for this choice being the default strategy.