But what deterministic order do you use? Any order seems problematic to me, once loops are involved. Certainly if you just pick a naive order like "lowest entity ID runs first", then you end up with a lot of items not moving when they should, since the cell in front of them is still full even though it'll empty later this tick.
And what would you do if you want the entirely full loop to not jam? It sounds possible, probably even simple, but I haven't seen how. A solution to this problem is orthogonal to the points you've raised.
> you end up with a lot of items not moving when they should, since the cell in front of them is still full even though it'll empty later this tick.
That's actually not as big a problem as you'd expect. You would end up with 1-tick gaps, but at 60 ticks-per-second, those kinds of gaps don't end up being an issue, especially when you've got a backed-up buffer that has some natural hysteresis waiting to fill that gap.
> And what would you do if you want the entirely full loop to not jam? It sounds possible, probably even simple, but I haven't seen how.
Compute the graph of connectivity at entity construction, precompute a topological iteration order, and handle each strongly-connected component as an individual entity. Or maybe you could do it with merely a list of elementary cycles; it would take some work to figure out what you want the semantics of loop motion to be if a belt is in multiple loops.
Avoiding one-tick hiccups was exactly what got me thinking about this. I've only played Mindustry and it looks like the tick rate is slower there with all conveyor belt movement happening in discrete one-cell-at-a-time movements (animated to look smooth). I'm surprised to hear that Factorio might just ignore the problem (though typical conveyor belt graphs are probably loop-free and not so hard).
> precompute a topological iteration order
So do you mean the a topological sorting as in [1]? That won't be possible with cycles, of course, so I don't think I know what you mean. I agree that I haven't fully specified the desired specification, but I'd probably be satisfied with something that satisfies: "chooses a movement such that it is impossible to move any additional items this tick". So maybe of two joined loops only one moves this tick, so long as its movement makes the other one impossible to move, but move both if possible. And any isolated loop always has to move.
And what would you do if you want the entirely full loop to not jam? It sounds possible, probably even simple, but I haven't seen how. A solution to this problem is orthogonal to the points you've raised.