How does Helm handle latency that appears only under concurrent install or upgrade commands?

Goal: Determine whether Helm v3 can reduce latency spikes observed when multiple helm install or helm upgrade commands run concurrently without relying on external serialization.

Constraints/uncertainty: The observed latency stems from Kubernetes API server queuing, etcd lock contention, and overlapping exponential backoff retries; it is unclear if adding a built‑in concurrency limit would conflict with Helm’s stateless design or affect existing automation workflows.

Specific questions: Does the Helm community consider adding a configurable concurrency‑limit flag to helm install/helm upgrade? What trade‑offs (e.g., reduced parallelism, API‑server load) would such a flag introduce? How could users validate the effectiveness of internal throttling versus external tooling in their own clusters?