It would be great if RateLimiterQueue could use RateLImiterUnion
Doesn't look like it would be a massive change, as the main issue seems to be handling the reject on the consume of the Union limiter, and checking for the maximum msBeforeNext of the rejection sub-limiters.

Similarly it would be nice if the Queue limiter could expose msBeforeNext from the underlying limiter in the exception provided when removeTokens() calls fails (for all underlying limiters, not just Union - perhaps there is already an easy way of doing this that I've missed?).

Conversely, RateLimiterUnion being able to handle RateLimiterQueues as a child limiter would also be handy, I realise the api for the queue limiter isn't consume based, but perhaps not impossible to make it look like it was from the top level Union point of view, especially if the Queue was able to expose msBeforeNext.

Anyway, only had a quick look at the code, so there might be fundamental architecture reasons why neither of these ideas make sense, so close and ignore if that's the case. Figured if the Queue and Union were a bit more  composable , it would add to the flexibility of an already extremely flexible system. Thanks for all the time you've spent on the project!
