gRPC max concurrent streams per connection: tuning stream limits versus opening additional connections

I am configuring a gRPC client and server pair that will handle bursts of concurrent unary calls, and I need to settle one configuration decision: how many concurrent HTTP/2 streams to allow per connection versus when to open additional connections.

My understanding is that gRPC multiplexes streams over a single HTTP/2 connection, and that the maximum concurrent streams per connection is negotiated between peers, with defaults that differ across language implementations (Go, Java, C-core). I assume current stable releases of each, but I have not confirmed the exact defaults per version.

The constraint I cannot resolve from documentation alone: when concurrent demand approaches the negotiated stream limit, queued streams appear to wait for capacity on the existing connection rather than spilling to a new one, and there seems to be no cross-language standard or documented recommendation for the trade-off between raising the per-connection stream limit and scaling the connection pool.

Related uncertainty: the HTTP/2 flow control window (per stream and per connection) may throttle large concurrent payloads independently of the stream count limit, and I am unsure how the two limits interact when both are near exhaustion.

1. Is there a documented or recommended basis for choosing a max concurrent streams value, or is it purely empirical per workload?

2. At what point should a client open additional connections instead of raising the stream limit on one connection?

3. Which transport metrics best indicate that stream-limit queuing, rather than flow control, is the binding constraint?