constantConcurrentUsers + throttle vs constantUsersPerSec for bounded Gatling heap at target RPS

The goal is to hold a target request rate while keeping the Gatling load generator's own heap bounded, but the two documented injection strategies pull in opposite directions. A closed-workload profile such as constantConcurrentUsers(n).during(d) combined with throttle(...reachRps(r)...) keeps N sessions resident for the entire run, so memory scales with concurrency times session and feeder size. An open-workload profile such as constantUsersPerSec(r).during(d) keeps only short-lived users, so resident sessions track response time times arrival rate.

The unresolved behavior is that throttle acts only as a cap, never as a generator: if the injection profile cannot supply enough concurrent users, or the system under test is too slow, the reachRps target is silently missed without raising an error. With the closed profile, slower responses make users queue inside Gatling instead of shedding load, which can grow heap through pending requests and retained sessions. With the open profile, arrivals decouple from response time, but overshoot can overload the target.

Which profile better bounds load-generator memory when system-under-test latency is variable? Can throttle steps be configured to fail or warn when a reachRps step is not actually reached? Does the feeder replay strategy materially change the resident-memory trade-off between the two profiles?