You would put both operators into a group and reference this group in a Process Flow resource, so both sides of the Process Flow acquire the operator from the same, shared pool.
To control priorities, you then use the query field in the Acquire activity and the Back Order Strategy of the Resource activity.
To be able to do this, you need to be able to distinguish between the operators which can be done by giving them a label with different values ("Id" in the attached model). You can then filter for a specific Id value or order by this value, prioritizing operators with lower or higher values.
The Back Order Strategy (see 'Advanced' options when clicking on the Resource) determines which token gets to acquire an operator if there are multiple tokens waiting. Here, you could for example also give the tokens a label that denotes which station they belong to. The following expression then compares this label ("StationId") to that of the operator. The comparison either returns 1/true or 0/false. If you order by this result in descending order, tokens of station 2 will have higher priority when pulling operator 2 and vice versa.

items_pull_operator_fm.fsm
Another, possible somewhat more intuitive way of modelling this would be to have each token represent an operator. These tokens would then pull items. Rather than each token representing an item and pulling an operator.
For this, the tokens that are created when an item enters a queue would push the item onto a list, after writing a label to them that denotes the station. You can then set up the query in a Pull From List activity so that the 'operator-tokens' preferably pull items from 'their' station.
operators_pull_items_fm.fsm