Does this happen with all shared modes? I would think, that it is most problematic, when calculateSharedDelay(ThroughputInfo, long) is used. The delay would be rounded too early there.
That would be the modes with (shared).

And another question is, how many threads had your thread group?

After looking a bit deeper here, I think the resolution of milliseconds for the calculated delay is not enough, when we are trying a high throughput rate with a low thread count.
For example, if we set 30,000 or 40,000 requests as a target with one thread and use active thread as the mode. Then the calculation for the two request/s targets would be:

30,000 => 60,000/30,000 = 2 => rounded to 2
40,000 => 60,000/40,000 = 1.5 => rounded to 2

It doesn't change, when we calculate the same with microseconds instead and still round at the end, as it would be:

30,000 => 60,000,000/30,000 = 2,000 => round to milliseconds => 2
40,000 => 60,000,000/40,000 = 1,500 => round to milliseconds => 2

Apart from this, it is probably still a good idea to change the resolution.

Does this happen with all shared modes? I would think, that it is most problematic, when calculateSharedDelay(ThroughputInfo, long) is used. The delay would be rounded too early there. That would be the modes with (shared).

It happens with all shared modes. And I think you are right, the root cause is the delay rouned too early. Calculate with microseconds can't solve the problem thoroughly.

After looking a bit deeper here, I think the resolution of milliseconds for the calculated delay is not enough, when we are trying a high throughput rate with a low thread count. For example, if we set 30,000 or 40,000 requests as a target with one thread and use active thread as the mode. Then the calculation for the two request/s targets would be:

30,000 => 60,000/30,000 = 2 => rounded to 2 40,000 => 60,000/40,000 = 1.5 => rounded to 2

It doesn't change, when we calculate the same with microseconds instead and still round at the end, as it would be:

30,000 => 60,000,000/30,000 = 2,000 => round to milliseconds => 2 40,000 => 60,000,000/40,000 = 1,500 => round to milliseconds => 2

Apart from this, it is probably still a good idea to change the resolution.

Use microseconds may be quite different when Math.max(now, nextRequestTime), and then the result of this will produce an effect on the delay. But calcuate with microseconds will still have the problem when the throughput rate is high enough.