Original text:
application to make the mapping of data to streams dependent on this information. <del> While a QUIC implementation must necessarily provide a way for an application to send data on separate streams, it does not necessarily expose stream identifiers to the application (see, for example, QUIC- HTTP, Section 6) either at the sender or receiver end, so applications should not assume access to these identifiers. </del>  4.1.

Reviewer comments:
I believe it is sane to not assume a specific ID ordering, but I do not think it is right to require that all applications do not so. You can easily have applications that benefit from knowing and controlling the ID sequencing in detail, but such applications may not be implementable on the majority of QUIC library implementations. Ops should only make this a guidance for designing new app level protocols, not a requirement.
I would see everything in the ops docs as a recommendation and not a requirement. However this PR is already merged. Can you open a new issue (and ideally propose some wording or say more specifically where you think the current wording is too restrictive)?
NAME done
Follow up to comment on The current text: might vary between transport implementations. Therefore, an application should not assume a particular stream ID will be assigned to a stream that has not yet been allocated. For example, HTTP/3 uses Stream IDs to refer to streams that have already been opened, but makes no assumptions about future Stream IDs or the way in which they are assigned. Specifically "An application should not assume a particular stream ID will be assigned to a stream that has not yet been allocated. " This highly depends on the application protocol, not the QUIC transport API. It may be that a given QUIC transport protocol is unable to support the requirements of a QUIC application protocol, but it is the app protocol that decides. If a given QUIC transport API only supports "OpenNextStreamOfType(x)" that might be enough to support HTTP/3. But it should be be that all app protocols follow the same constraints. However, it is reasonable to recommend that application level protocols attempts to avoid a dependency on a specific stream ID in order to be able to target a broader range of QUIC transport libraries and to avoid unnecessary dependencies while at the same time permitting this for specific use cases.
I not sure what you are missing here or what you think should be changed. For me the text is inline with what you say, which basically is: to be on the safe side you better make no assumption about how non-yet assigned ID will be used because there is no unified way how this is specified in the protocol spec. So, basically saying even if the interface seem to provide that, be careful here!
The text "An application should not assume a particular stream ID will be assigned to a stream that has not yet been allocated. " basically says that you should not design protocols that rely on stream IDs have any particular meaning. But you could easily design such protocols safely, but it will only work for transport libraries that permit such close coordination. Personally I think it is best to avoid such dependencies in most cases, but that shouldn't prevent special purpose protocols from existing. For example, a telemetric protocol might define that streams 1 through 100 (modulo stream type) each indicate a log level of implied severity.
This is a recommendation not a normative SHOULD. We are only trying to provide guidance but if you are a specialised application and you know what you are doing you can of course do that.
NAME can we close this issue or would you like to propose a wording change?
Seeing no further action/suggestion, closing. Please reopen if there's a concrete change to make.
The ops draft currently says: to send data on separate streams, it does not necessarily expose stream identifiers to the application (see, for example, {{QUIC-HTTP}}, Section 6) either at the sender or receiver end, so applications should not assume access to these identifiers. I don't see anything in Section 6 of HTTP/3 to support that claim. In fact, HTTP/3 uses Stream IDs in the GOAWAY frame to indicate the last request the server processed; both client and server will require access to the identifiers of streams, or that information is impossible to generate and useless to receive. The constraint that I tried to use when writing the HTTP draft was that the application layer has no control over the assignment of Stream IDs. However, once it has requested and been given a stream, it can retrieve the ID of that stream and use it to reference the stream at the application layer. By the same token, the application layer shouldn't assume it understands the relationship between stream types and Stream IDs; that may change in a future QUIC version, and it should rely on querying the stream properties to identify types.
Actually writing these constraints/assumptions down would be nice. Can you try to create a PR, NAME ?
That captures it.

Revised text:
application to make the mapping of data to streams dependent on this information.  <ins> QUIC assigns a numerical identifier to each stream, called the Stream ID.  While the relationship between these identifiers and stream types is clearly defined in version 1 of QUIC, future versions might change this relationship for various reasons.  QUIC implementations should expose the properties of each stream (which endpoint initiated the stream, whether the stream is unidirectional or bidirectional, the Stream ID used for the stream); applications should query for these properties rather than attempting to infer them from the Stream ID. The method of allocating stream identifiers to streams opened by the application might vary between transport implementations.  Therefore, an application should not assume a particular stream ID will be assigned to a stream that has not yet been allocated.  For example, HTTP/3 uses Stream IDs to refer to streams that have already been opened, but makes no assumptions about future Stream IDs or the way in which they are assigned. </ins> 4.1.