Change:
Also includes changes to a paragraph that will be Section 3 after the pending intro-shoving. Rationale as in the review response mail: Reference made more precise, "from a single endpopoint" added. Split up into separate sentences for better clarity. That requirement was already kind of conditional on the client using Request-Tag for a particular purpose -- for otherwise the "unless concluded" clause makes no sense, for that's defined by the purpose. Rephrased to pull in the purpose before the MUST and make that explicit. The "that support Request-Tag" comment should be obsolete by hat, for only who supports it can use it for something. (We did, in the chat earlier, consider asking the WG whether that'd all mean that we're updating RFC7959, but as we're now back to "If you want to achieve X, do Y" wording, I don't see necessity for such an update). Added to the initial (now split up) paragraph of that section. Explicitly included as an option now. (Would have been even easier if there were a once-and-for-all definition of a "request-tag value" that can be absent or have the option's data, but that had long-winded wording in the last version that was in, and still might be mistaken by readers that don't have the precise definition at hand).
Looks good.

Discussion:
Two matchable block-wise operations are said to be "concurrent" if a block of the second request is exchanged even though the client still intends to exchange further blocks in the first operation. <del> (Concurrent block-wise request operations are impossible with the options of RFC7959 because the second operation's block overwrites </del> <ins> (Concurrent block-wise request operations from a single endpoint are impossible with the options of RFC7959 (see the last paragraphs of Sections 2.4 and 2.5) because the second operation's block overwrites </ins> any state of the first exchange.). The Echo and Request-Tag options are defined in this document.

assumptions about its content or structure. Two messages carrying the same Request-Tag is a necessary but not <del> sufficient condition for being part of the same operation.  They can still be treated as independent messages by the server (e.g. when it sends 2.01/2.04 responses for every block), or initiate a new operation (overwriting kept context) when the later message carries Block1 number 0. </del> <ins> sufficient condition for being part of the same operation.  For one, a server may still treat them as independent messages when it sends 2.01/2.04 responses for every block.  Also, a client that lost interest in an old operation but wants to start over can overwrite the server's old state with a new initial (num=0) Block1 request and the same Request-Tag under some circumstances.  Likewise, that results in the new message not being part of he old operation. </ins> As it has always been, a server that can only serve a limited number of block-wise operations at the same time can delay the start of the

3.3. For each separate block-wise request operation, the client can choose <del> a Request-Tag value, or choose not to set a Request-Tag.  Starting a request operation matchable to a previous operation and even using the same Request-Tag value is called request tag recycling.  The absence of a Request-Tag option is viewed as a value distinct from all values with a single Request-Tag option set; starting a request operation matchable to a previous operation where neither has a Request-Tag option therefore constitutes request tag recycling just as well (also called "recycling the absent option"). Clients MUST NOT recycle a request tag unless the first operation has concluded.  What constitutes a concluded operation depends on the application, and is outlined individually in req-tag-applications. </del> <ins> a Request-Tag value, or choose not to set a Request-Tag.  It needs to be set to the same value (or unset) in all messages belonging to the same operation, as otherwise they are treated as separate operations by the server. Starting a request operation matchable to a previous operation and even using the same Request-Tag value is called request tag recycling.  The absence of a Request-Tag option is viewed as a value distinct from all values with a single Request-Tag option set; starting a request operation matchable to a previous operation where neither has a Request-Tag option therefore constitutes request tag recycling just as well (also called "recycling the absent option"). Clients that use Request-Tag for a particular purpose (like in req- tag-applications) MUST NOT recycle a request tag unless the first operation has concluded.  What constitutes a concluded operation depends on that purpose, and is defined there. </ins> When Block1 and Block2 are combined in an operation, the Request-Tag of the Block1 phase is set in the Block2 phase as well for otherwise

If any of them is matchable to the new one, and the client neither wants to cancel the old one nor postpone the new one, it can pick <del> a Request-Tag value that is not in use by the other matchable operations for the new operation. </del> <ins> a Request-Tag value (including the absent option) that is not in use by the other matchable operations for the new operation. </ins> Otherwise, it can start the new operation without setting the Request-Tag option on it.