An iteration's slot comes from its token, not from the loop's cursor

[noha]

Inside a parallel scope one activation serves every iteration of a node, with one slot per iteration. The slot was the executor's #index, which points at the newest iteration queued - while an earlier iteration may still be waiting and go on later. Two waits resumed in reverse order wrote both values into the second slot, and the node behind the scope join saw #(nil 'A').

Every iteration scope now knows its #index (FBScope), and a parallel activation reads its slot off its token's iteration scope (FBParallelActivation>>iterationIndex, FBParallelExecutor>>iterationOf:). The executor keeps a #currentIteration for what runs within a step or a resume - the loop variable and a predecessor's value are read for that iteration (#lastValueOf:, #outputFor:). A node resumed after a condition wait gets the parked token put back on its activation, so the slot the value goes into is the resumed iteration's.

Tokens without a scope, persisted before iterations had one, fall back to the cursor as before.