Original text:
MUST NOT consider these streams to have any meaning upon receipt. The payload and length of the stream are selected in any manner the <del> implementation chooses. </del>  7. The requested operation cannot be served over HTTP/3.  The peer should retry over HTTP/1.1.  9. HTTP/3 permits extension of the protocol.  Within the limitations The entries in the iana-error-table are registered by this document.  11.2.4. This document establishes a registry for HTTP/3 unidirectional stream

Reviewer comments:
Pleasantly, the same formula we've used for grease values elsewhere in HTTP/3 does not collide with any currently-assigned error code, so I've just reused it. (We'll need to be cautious about 0x119, though.) The same logic could be applied to transport error codes, but there's not much point. If you're intolerant of the way your peer closed the connection, you might erroneously... close the connection? Editorial-ish: A recommendation which reserves some error code space we haven't used; modifies the IANA instructions. Doesn't mandate or prohibit anything new.
Constraining the recommendation on grease streams, because sending any error code potentially generates an error code that has semantics to your peer of which you are unaware.
The discussion on made us conclude that the reason for doing this is that we want to safeguard our ability to define new error codes. Greasing might help with that.
Since you'd probably want want the grease to not sacrifice connections it might make sense to couple grease error codes to H3 grease streams. Also, what about greasing of transport-level error codes? Can't play the stream tricks there.
Unknown error codes are supposed to be equivalent to H3NOERROR. Perhaps a recommendation (SHOULD) to substitute a grease code with non-zero probability when you would have sent NO_ERROR? And MAY use them when terminating grease streams, sure.
Looks fine to me. I wonder how much this will end up doing anything...LG, but I think it's worth accepting Martin's suggestion.

Revised text:
MUST NOT consider these streams to have any meaning upon receipt. The payload and length of the stream are selected in any manner the  <ins> implementation chooses.  Implementations MAY terminate these streams cleanly, or MAY abruptly terminate them.  When terminating abruptly, the error code H3_NO_ERROR or a reserved error code (http-error- codes) SHOULD be used. </ins> 7. The requested operation cannot be served over HTTP/3.  The peer should retry over HTTP/1.1. <ins> Error codes of the format "0x1f * N + 0x21" for integer values of N are reserved to exercise the requirement that unknown error codes be treated as equivalent to H3_NO_ERROR (extensions).  Implementations SHOULD select an error code from this space with some probability when they would have sent H3_NO_ERROR. </ins> 9. HTTP/3 permits extension of the protocol.  Within the limitations The entries in the iana-error-table are registered by this document. <ins> Additionally, each code of the format "0x1f * N + 0x21" for integer values of N (that is, "0x21", "0x40", ..., through "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. </ins> 11.2.4. This document establishes a registry for HTTP/3 unidirectional stream