In HTTP/2 a connection responsible for creating and stream and all resources related to it. Http2Stream creation and reuse are all handled by Http2Connection.

In HTTP/3 a stream extends into the QUIC transport layer. Http3Connection creates Http3Stream and QuicConnection creates QuicStreamContext. For high performance, both these need to be cached and reused.

tldr; cache should move into the transport layer

Detail:

1. A concurrent queue is added to QuicConnection. It acts as a cache for completed QuicStreamContext instances.
2. When accepting a stream on a connection, the queue is checked for existing QuicStreamContext instances. An instance is reused if available. Otherwise, a new QuicStreamContext is created. The stream has a reference to its connection.
3. There isn't an API to "return" a stream to the connection on MultiplexedConnectionContext. Instead, returning will be implicit with disposing of QuicStreamContext. When a cleanly completed (i.e. neither side of the stream was aborted) stream is disposed it will add itself to its QuicConnection concurrent queue cache so it can be reused.
4. We're now reusing the QuicStreamContext 🥳 We also want to reuse the Http3Stream. Rather than having a separate cache, the feature collection on the stream transport - QuicStreamContext.FeatureCollection - is used to stash Http3Stream. A reused QuicStreamContext will have a Http3Stream on it to reuse.

Caching and reusing streams should only be necessary for request streams (i.e. bidirectional streams) on an HTTP/3 connection. There isn't value in caching and reusing unidirectional streams. Only a handful are created for a connection and they will live for the lifetime of the connection.