Clarification on ordering with concurrency controls

[ric2b]

In the README section on concurrency controls we can find this:

Jobs are unblocked in order of priority but queue order is not taken into account for unblocking jobs. That means that if you have a group of jobs that share a concurrency group but are in different queues, or jobs of the same class that you enqueue in different queues, the queue order you set for a worker is not taken into account when unblocking blocked ones.

I assume, although I couldn't find it documented, that if the job group is entirely on a single queue, that queue order will still be respected within each concurrency key, correct? And this warning is about how mixing different queues does not guarantee any order between the different queues?

Or does using concurrency control on a single queue also throw out queue ordering within a key?

My use case is queue fairness (preventing a user from monopolizing the queue by flooding it with a lot of jobs and causing other users to wait a long time), concurrency controls seem to be a decent solution by allowing me to rate limit each user (by using user_id as key) to N concurrent jobs with N being smaller than the capacity of the worker pool.

If concurrency controls change the order within a single queue in the sense that a job from user A might be executed before a job from user B that was enqueued earlier, because B is rate limited, that would be fine and intended. But if the jobs of a user are executed out of order that's potentially a problem.

Could someone clarify how concurrency control ordering works in the context of a single queue, and if it's viable for the queue fairness use case?