Code change:
making further progress.  At this stage connections can be terminated via idle timeout or explicit close; see sec-termination). <del> An application that uses QUIC might communicate a cumulative stream limit but require the connection to be closed before the limit is </del> <ins> An application that uses QUIC and communicated a cumulative stream limit might require the connection to be closed before the limit is </ins> reached.  For example, to stop the server to perform scheduled maintenance.  Immediate connection close causes abrupt closure of actively used streams.  Depending on how an application uses QUIC streams, this could be undesirable or detrimental to behavior or <del> performance.  A more graceful closure technique is to stop sending increases to stream limits and allow the connection to naturally terminate once remaining streams are consumed.  However, the period of time it takes to do so is dependent on the client and an unpredictable closing period might not fit application or operational needs.  Applications using QUIC can be conservative with open stream limits in order to reduce the commitment and indeterminism.  However, being overly conservative with stream limits affects stream concurrency.  Balancing these aspects can be specific to applications and their deployments.  Instead of relying on stream limits to avoid abrupt closure, an application-layer graceful close mechanism can be used to communicate the intention to explicitly close the connection at some future point. HTTP/3 provides such a mechanism using the GOAWAY frame.  In HTTP/3, when the GOAWAY frame is received by a client, it stops opening new streams even if the cumulative stream limit would allow.  Instead the client would create a new connection on which to open further streams.  Once all streams are closed on the old connection, it can be terminated safely by a connection close or after expiration of the idle time out (see also sec-termination). </del> <ins> performance. A more graceful closure technique is to stop sending increases to stream limits and allow the connection to naturally terminate once remaining streams are consumed.  However, the period of time it takes to do so is dependent on the peer and an unpredictable closing period might not fit application or operational needs.  Applications using QUIC can be conservative with open stream limits in order to reduce the commitment and indeterminism.  However, being overly conservative with stream limits affects stream concurrency.  Balancing these aspects can be specific to applications and their deployments. Instead of relying on stream limits to avoid abrupt closure, an application-layer graceful close mechanism can be used to communicate the intention to explicitly close the connection at some future point.  HTTP/3 provides such a mechanism using the GOAWAY frame.  In HTTP/3, when the GOAWAY frame is received by a client, it stops opening new streams even if the cumulative stream limit would allow. Instead the client would create a new connection on which to open further streams.  Once all streams are closed on the old connection, it can be terminated safely by a connection close or after expiration of the idle time out (see also sec-termination). </ins> 5.

Related discussion:
text: “ I'm not so happy with currently here: Is this the best way to say this, might it be better to say this rather than even hinting that future QUIC might only be reliable: “When a QUIC endpoint provides provides fully reliable stream transmission, prioritization of retransmissions will be beneficial in most cases, by filling in gaps and freeing up the flow control window. “ 3) I’d prefer to see a ref here, since this something that the WG might later decide to work upon: “Currently QUIC only supports failover cases [Quic-Transport].”
That mega paragraph has a bunch of good concepts, but it's all run together into a single blob, which makes it a bit hard to follow.