Change:
5.1.2. <del> Either client or server can cancel requests by aborting the stream (QUIC RESET_STREAM and/or STOP_SENDING frames, as appropriate) with an error code of HTTP_REQUEST_CANCELLED (http-error-codes).  When the client cancels a response, it indicates that this response is no longer of interest.  Implementations SHOULD cancel requests by aborting both directions of a stream. When the server aborts its response stream using HTTP_REQUEST_CANCELLED, it indicates that no application processing was performed.  In this context, "processed" means that some data from the stream was passed to some higher layer of software that </del> <ins> Clients can cancel requests by aborting the stream (QUIC RESET_STREAM and/or STOP_SENDING frames, as appropriate) with an error code of HTTP_REQUEST_CANCELLED (http-error-codes).  When the client cancels a response, it indicates that this response is no longer of interest. Implementations SHOULD cancel requests by aborting both directions of a stream. When the server rejects a request without performing any application processing, it SHOULD abort its response stream with the error code HTTP_REQUEST_REJECTED.  In this context, "processed" means that some data from the stream was passed to some higher layer of software that </ins> might have taken some action as a result.  The client can treat <del> requests cancelled by the server as though they had never been sent at all, thereby allowing them to be retried later on a new connection.  Servers MUST NOT use the HTTP_REQUEST_CANCELLED status for requests which were partially or fully processed. </del> <ins> requests rejected by the server as though they had never been sent at all, thereby allowing them to be retried later on a new connection. Servers MUST NOT use the HTTP_REQUEST_REJECTED error code for requests which were partially or fully processed.  When a client sends a STOP_SENDING with HTTP_REQUEST_CANCELLED, a server MAY indicate the error code HTTP_REQUEST_REJECTED in the corresponding RESET_STREAM if no processing was performed.  Clients MUST NOT reset streams with the HTTP_REQUEST_REJECTED error code except in response to a QUIC STOP_SENDING frame. </ins> If a stream is cancelled after receiving a complete response, the client MAY ignore the cancellation and use the response.  However, if

Discussion:
This change sounds good to me, but to make sure I understand: is the only purpose of this change to split HTTPREQUESTCANCELLED in two; client to server stays HTTPREQUESTCANCELLED and server to client now becomes HTTPREQUESTREJECTED? And is the goal to add clarity when parsing connection logs later?
NAME basically. In the previous text, CANCELLED had specific semantics when sent server->client. However, with the change to make RESETSTREAM reflect back the error code in STOPSENDING, the client->server STOPSENDING(CANCELLED) would provoke a RESETSTREAM(CANCELLED) in the server->client direction with that error code that didn't necessarily match those semantics. Hence the split -- one code has specific semantics when sent by a server, and clients are instructed to use the other code. (I would prohibit clients from sending it, but if the server sends a STOP_SENDING, the client would reflect it back and violate the prohibition, so....)