Packer concurrent builds show latency without per-build resource controls

Understanding latency that appears only when multiple Packer builds run in parallel is a design question about contention versus tool behavior. Packer itself does not enforce build concurrency; each build runs as a separate CLI process. Under concurrent execution, host-level resource contention and overlapping provider interactions can increase overall build time.

Plugin architecture loads provider plugins at build start-up, and several builds targeting the same provider can share backend storage and API rate limits. Packer debug logs timestamp step start and end times but do not capture cross-process contention, making attribution difficult. There is no documented per-build resource quota or isolation mechanism in core to limit CPU, disk I/O or network usage for parallel runs.

Assuming current Packer releases, does Packer expose any built-in mechanism to limit resource usage per build when runs are orchestrated in parallel? Which observable signals distinguish host contention from provider throttling in concurrent scenarios? Is a build-queue or concurrency control feature planned for core rather than community plugins?