I’ll revisit this again (probably next week) but I couldn’t find any indication of a bug.
The constraint solver was processing all the correct constraints and attempting to drive to both a target velocity of 1 and a target velocity of 2. The normal force applied to resolve the contacts were significantly smaller with the faster conveyor than the slower conveyor, so the friction with the slower conveyor was stronger and resulted in the velocity only slightly increasing until it was completely transferred to the faster conveyor. Friction force is in the range -un <= f <= un, where u = friction coefficient and n = normal force, so given an object resting on 2 surfaces moving at different speeds, friction will always be strongest on the surface that applies the most normal force.
When the box is accelerating on the conveyor, the frictional force pushing it forwards causes an angular velocity that is resisted by the rear contacts. This means there is more normal force applied through the rear contacts than the front contacts while accelerating. Once the box reaches the target speed, the frictional force tends towards zero and the normal forces become more evenly distributed.
When the box reaches the faster conveyor, the weight is supported more-or-less entirely by the first conveyor until the COM transfers - as I mentioned, if a coin was flipped and the faster conveyor was processed first, the results may be ever-so-slightly different but, after a few iterations, it would converge on a similar result for reasons described in the next paragraph. You don’t have control over the order that pairs are processed - it just comes down to how they come from the island manager, which is generally the order in which the pairs were created. While there are differences in behaviour if the constraints are reordered, there generally isn’t a single “correct” answer with complex N-body physics scenarios. However, with gauss-seidel style solvers, the constraints that are solved later have the ability to overpower those solved earlier in the iteration (last word wins), so this is actually the case where, if it were possible, the faster conveyor should have won if there was a 50/50 battle.
As more of the box transfers to the faster conveyor, there is increasing normal force with the faster conveyor on the front contacts. However, the acceleration from increased friction causes an angular velocity which causes the normal force to shift to the rear contacts on the slower conveyor and decrease on the front contacts (on the faster box). The rear contacts allow an increased amount of friction (driving towards a velocity of 1). There’s a back-and-forth struggle between the front and rear contacts because normal force from the rear contacts and frictional deceleration from the rear contacts also causes some angular velocity that moves some of the normal force back to the front contacts. This will be why more iterations seems to cause acceleration to occur a little earlier. However, the result seems to consistently be that there is more normal force on the rear contacts and its friction holds strong until the box has more-or-less completely transferred to the faster conveyor.
As far as I can tell, this is all physically fairly accurate.