TL;DR:
Does Gatling already have a feature that lets me specify this:
rampUsersPerSec( 0 ) to ( 1,000 ) during ( 2 hours ) limit ( 800 )
Instead of this:
rampUsersPerSec( 0 ) to ( 800 ) during ( 1.6 hours ), constantUsersPerSec( 800 ) during( 0.4 hours )
And I don’t mean throttling at the scenario level, I mean altering the effective injection profile based on some limit.
I know, strange question. Here’s the context so you understand why I’m asking:
I am building simulations that have embedded within them a concept of a target rate, e.g. 2,000 users per hour, which represents the average volume in production at peak times for users following that usage pattern (scenario).
I have a concept of a multiplier, so I can code the test in the same language that the business frames the ask, namely, “What happens when you run the test at 2x of production volume?” Or, “At what multiple of current volume does the system keel over?”
The expectation when you do a ramp test, say, from 0x to 10x over 10 hours, is that at any given point, the traffic pattern is a fair representation of what the traffic would look like if you just increased the number of users by that multiplier. We will ignore for now the idiocy of that assumption. We know that growth is seldom not accompanied by a shift in the distribution of tasks performed, but projection requires constraints, and this is the constraint we have chosen for this particular exercise. 
But sometimes there is an additional constraint: Feature X will never grow past Y number of transactions/users per hour. Meaning, 2x of the system as a whole means 2x of feature X. But we, the business, or the development team, are asserting that for the sake of projecting forward, assume a hard ceiling on the number of requests per hour for feature X. Maybe because there is rate limiting imposed. Again, we will ignore whether that is a reasonable constraint or not, and just focus on what that means for the test:
As long as the result of 1x traffic volume of feature X times the current multiplier is less than the limit, the expectation is that that’s how many transactions/users will be injected for feature X. But once you cross the threshold, the growth stops. If the limit is less than the target, then growth will stop before the ramp up period is completed.
If I do a naive implementation where I do a linear ramp over the ramp up time, but calculate the ramp target as the minimum of the limit or the target, then instead of stopping the ramp prematurely, it simply ramps too slowly.
Now, I can code for the premature plateau of the ramp by altering the ramp up duration and sustain duration based on how early in the ramp we are expected to reach the limit. I can do it. But I feel like it is not the cleanest way of representing what is going on in the test.
And since historically, Gatling has far more bells and whistles than I can keep track of, I figured it didn’t hurt to ask.