Original text:
HTTP/3 does not use server-initiated bidirectional streams, though an extension could define a use for these streams.  Clients MUST treat receipt of a server-initiated bidirectional stream as a connection <del> error of type HTTP_GENERAL_PROTOCOL_ERROR unless such an extension has been negotiated. </del>  6.2. by the recipient, the remainder of the stream cannot be consumed as the semantics are unknown.  Recipients of unknown stream types MAY trigger a QUIC STOP_SENDING frame with an error code of <del> HTTP_UNKNOWN_STREAM_TYPE, but MUST NOT consider such streams to be a connection error of any kind. </del>  Implementations MAY send stream types before knowing whether the peer supports them.  However, stream types which could modify the state or HTTP_MISSING_SETTINGS.  Only one control stream per peer is permitted; receipt of a second stream which claims to be a control stream MUST be treated as a connection error of type <del> HTTP_WRONG_STREAM_COUNT.  The sender MUST NOT close the control </del>  stream, and the receiver MUST NOT request that the sender close the control stream.  If either control stream is closed at any point, this MUST be treated as a connection error of type Only servers can push; if a server receives a client-initiated push stream, this MUST be treated as a connection error of type <del> HTTP_WRONG_STREAM_DIRECTION. </del>  Each Push ID MUST only be used once in a push stream header.  If a push stream header includes a Push ID that was used in another push N/A <del> A unidirectional stream header contained an unknown stream type. </del>  <del> A unidirectional stream type was used more times than is permitted by that type. </del>  A stream required by the connection was closed or reset. <del> A unidirectional stream type was used by a peer which is not permitted to do so. </del>  The remainder of the client's request is not needed to produce a response.  For use in STOP_SENDING only.

Reviewer comments:
There are presently several kinds of very similar error when creating streams: HTTPUNKNOWNSTREAMTYPE MAY be used to tell a peer to STOPSENDING on a stream type that is unknown by the local peer. It is not a connection error. HTTPWRONGSTREAMCOUNT MUST be used if a peer tries to open more than one critical stream (control, QPACK). Connection error. HTTPWRONGSTREAMDIRECTION MUST be used if a client tries to open a push stream. More generally this could be used if a peer attempts to open a stream type that is not allowed to, but push is the only example today. Connection error. The suggestion is to rationalize these into a single error code - HTTPSTREAMCREATIONERROR - that can be used in STOPSENDING or CLOSECONNECTION. The impact of merging COUNT and DIRECTION is minimal because implementations fundamentally have to open streams correctly in order to interop. PS. The eagle eyes will notice I omitted the HTTPDUPLICATE_PUSH creation error. This is on the chopping block in . I class it differently because it is about parsing information after the stream type.
Should a client respond with STREAMCREATIONERROR when it sees the server opening a bidirectional stream? At the moment the designated error code is HTTPGENERALPROTOCOLERROR, but STREAMCREATIONERROR might be a better fit. Or if we are not going to use STREAMCREATIONERROR for server-initiated bidirectional streams, I think we should better rename it to UNIDIRECTIONALSTREAMCREATIONERROR to avoid confusion.
This relates to some earlier discussion on URL and its now-merged PR URL We only recently added text to specify the use of HTTPGENERALPROTOCOLERROR in this case, I think it fits to modify this to STREAMCREATION_ERROR.
Changed in URL

Revised text:
HTTP/3 does not use server-initiated bidirectional streams, though an extension could define a use for these streams.  Clients MUST treat receipt of a server-initiated bidirectional stream as a connection  <ins> error of type HTTP_STREAM_CREATION_ERROR unless such an extension has been negotiated. </ins> 6.2. by the recipient, the remainder of the stream cannot be consumed as the semantics are unknown.  Recipients of unknown stream types MAY trigger a QUIC STOP_SENDING frame with an error code of  <ins> HTTP_STREAM_CREATION_ERROR, but MUST NOT consider such streams to be a connection error of any kind. </ins> Implementations MAY send stream types before knowing whether the peer supports them.  However, stream types which could modify the state or HTTP_MISSING_SETTINGS.  Only one control stream per peer is permitted; receipt of a second stream which claims to be a control stream MUST be treated as a connection error of type  <ins> HTTP_STREAM_CREATION_ERROR.  The sender MUST NOT close the control </ins> stream, and the receiver MUST NOT request that the sender close the control stream.  If either control stream is closed at any point, this MUST be treated as a connection error of type Only servers can push; if a server receives a client-initiated push stream, this MUST be treated as a connection error of type  <ins> HTTP_STREAM_CREATION_ERROR. </ins> Each Push ID MUST only be used once in a push stream header.  If a push stream header includes a Push ID that was used in another push N/A  <ins> The endpoint detected that its peer created a stream that it will not accept. </ins>  <ins> N/A </ins> A stream required by the connection was closed or reset.  <ins> N/A </ins> The remainder of the client's request is not needed to produce a response.  For use in STOP_SENDING only.