Anonymous,
lets see if I understood. You have one queue with messages having (let's keep it simple) two different priorities. Let's say high and low. You have two orchestrations which subscribe for messages on the queue and filter high and low messages as appropriate.
Now, your problem is to arrange that the high priority orchestrations get processed as quickly as possible, at the expense of the low priority items.
Is this correct?
One thing you don't mention is whether high priority items can interrupt already running low priority orchestrations. Anyway, assuming not, why not have a component which orchestrations ask "Can I go ahead?" Then it's very easy to tune the behaviour.
But I think the problem is that you don't really want the 'queue' behaviour – first-in, first-out. Perhaps if you have a component which is peeking at the head of the queue – if it's not high priority, then check if there is a high priority coming along and take that instead and drop that for an orchestration. Then just choke the number of orchestration instances.
I bet there's a ton of academic literature about modified queue behaviour with different priority messages!
John D.