Change:
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

Discussion:
tracks the Known Received Count in order to identify which dynamic table entries can be referenced without potentially blocking a stream.  The decoder tracks the Known Received Count in order to be <del> able to send Insert Count Increment instructions (see insert-count- increment). If a header block was potentially blocking, the encoder infers from receiving a Header Acknowledgement instruction (header- acknowledgement) that the decoder has received all dynamic table state necessary to process that header block.  If the Required Insert Count of the acknowledged header block is greater than the current Known Received Count, the encoder updates the Known Received Count to the value of the Required Insert Count of the acknowledged header block. To acknowledge dynamic table entries which are not referenced by header blocks, for example because the encoder or the decoder have chosen not to risk blocked streams, the decoder sends an Insert Count Increment instruction (see insert-count-increment). </del> <ins> able to send Insert Count Increment instructions. A Header Acknowledgement instruction (header-acknowledgement) implies that the decoder has received all dynamic table state necessary to process corresponding the header block.  If the Required Insert Count of the acknowledged header block is greater than the current Known Received Count, Known Received Count is updated to the value of the Required Insert Count. An Insert Count Increment instruction insert-count-increment increases the Known Received Count by its Increment parameter.  See new-table-entries for guidance. </ins> 2.2.

Insert Count has already been acknowledged, that MUST be treated as a connection error of type "HTTP_QPACK_DECODER_STREAM_ERROR". <ins> The Header Acknowledgement instruction might increase the Known Received Count, see known-received-count. </ins> 4.4.2. When a stream is reset or reading is abandoned, the decoder emits a

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