Change:
The Insert Count Increment instruction begins with the '00' two-bit pattern, followed by the Increment encoded as a 6-bit prefix integer. <del> The value of the Increment is the total number of dynamic table insertions and duplications processed by the decoder since the last time it sent a Header Acknowledgement instruction that increased the Known Received Count (see known-received-count) or an Insert Count Increment instruction.  The encoder uses this value to update the Known Received Count, as described in state-synchronization. </del> <ins> This instruction increases the Known Received Count (see known- received-count) by the value of the Increment parameter.  The decoder should send an Increment value that increases the Known Received Count to the total number of dynamic table insertions and duplications processed so far. </ins> An encoder that receives an Increment field equal to zero, or one that increases the Known Received Count beyond what the encoder has

Discussion:
Fixes issue . This PR fixes the race condition and clarifies that both endpoints must keep track of the Known Received Count. Also remove "If a header block was potentially blocking" phrase from Known Received Count section, because it is redundant with the clear instructions on whether to increase the Known Received Count in the next sentence. Also remove "for example because the encoder or the decoder have chosen not to risk blocked streams" and defer to new-table-entries instead, so that all guidance on emitting Insert Count Increment instructions is in one place. Note that the decoder has no way to know if the encoder chose not to risk blocked streams, so I find this phrase confusing to start with.
Assume a decoder receives the following data: A: the first dynamic table insertion, B: the second dynamic table insertion, C: the third dynamic table insertion, X: a header block with required insert count of one. A, B, and C are guaranteed to be received in this order, because they are all on the encoder stream. X arrives on a request stream, so its order relative to the insertions is not guaranteed. Consider the orders A, B, X, C, and A, X, B, C. Suppose the decoder sends a Header Acknowledgement of the header block as soon as it is received (all necessary entries are available by that time). This Header Acknowledgement instruction increases the encoder's Known Received Count by one. Suppose that after receiving C, the decoder decides to send an Insert Count Increment instruction. According to URL, "The value of the Increment is the total number of dynamic table insertions and duplications processed by the decoder since the last time it sent a Header Acknowledgement instruction that increased the Known Received Count (see Section ) or an Insert Count Increment instruction." In the first case, one insertion (C) was processed since the last Header Acknowledgment instruction that increased the Known Received Count was sent. In the second case, two insertions (B and C). I'm ready to address this issue with a PR but waiting for review of issue 2942 which would conflict.
Ah, it needs to explicitly reference the Required Insert Count from the header block that was acked, rather than "since the last time". I think this is editorial, since that's the intent of the text.
I agree that it's editorial.

In I'm already proposing to mandate both the encoder and the decoder to keep track of the Known Received Count. Then Insert Count Increment could simply increase Known Received Count, without any references to previously acked header blocks if any etc.
Fixed by