"Right of way" can suck... in some conditions. Think of you sitting at a Stop Sign on a main highway.
I don't have a process fitting the particular case.
However, I'm willing to discuss the concept... it is, after all, simply a control problem.
So... you have two conveyor lines converging... apparently the items on the conveyors are spaced rather haphazardly.
Both lines come together at a particular point.
The speed of each line is controlled so as to ensure that the items from each line interlace without trying to place two items in the same space on the out-going conveyor.
So... let's try to visualize this...
Conveyor-A is of such-n-such length... it can hold X-items, tightly packed.
Conveyor-B is of such-n-such length... it can hold Y-items, tightly packed.
I have no reason to believe that the conveyors are the same length.
An initial stab at it involves a shift register for each conveyor.
Also, there is an encoder that tracks the relative position of the conveyor.
The "position-value" varies according to the speed of the conveyor. Hang on... there's a twist to this...
Looking at Conveyor-A, each item loaded onto Conveyor-A is "registered" with the current conveyor position according to the associated encoder position-count. At some point, the position-count is reset to... Maximum! This means, each subsequent pulse from the encoder causes a subtraction on the current position-count. In other words, the position-count works downward from maximum towards zero.
The same applies to Conveyor-B. This means that both conveyors are converging toward "zero".
Also, as each item is added to one conveyor, or the other, a counter is incremented to indicate the number of items on the particular conveyor. As an item leaves the conveyor, the count is decremented.
Also... the "registration" of the leading item, on each conveyor, is maintained in separate variables.
As a leading item of one conveyor is converged onto the out-going conveyor, the registration associated with that item is over-written by the registration of the following item on that conveyor.
So... you always have a positional relationship between the two leading items, as well as a total item-count on each conveyor.
Now... a critical consideration...
If one line is full and the other line has only one newly entered item, you might tend to let the full line run for the majority of the time...
However... unless there is a jam at the convergence point, both conveyors must run at some minimum speed. This is to ensure that the next item loaded onto a conveyor has room to be loaded. If either conveyor is stopped, for whatever reason, that conveyor can not accept new items.
Because of this, the conveyors must run at some minimum speed. That minimum speed is dependent upon the feed-rate from the source (manual or automated). Unless there is a way to regulate the source.
That means, the speeds of the conveyors can vary between that minimum speed and some maximum speed.
While the conveyors are moving, the encoder based current-position, logged into the shift-register for each conveyor, has to proceed forward with each new item entered onto the particular conveyor.
Now... the MGD-effect is starting to occur...
So... I'm done doing this head-bending for now.
The deal is... the speed of the conveyors is controlled by the position-count of the leading item, the total count of items on the conveyors, recognizing the minimum speed...
Gotta stop... Damn! I love MGD!
But I gotta say... this is a FUN problem!