All responses and completed delays are stored in a table with an auto-incremented id, so the `-await-next` will always resolve to the same value.
As you mention, putting a persistent sleep and a child execution into the same join set is not yet implemented.
The actual order in which child workflows finish and their results hit the persistence layer is indeed nondeterministic in real-time execution. Trying to force deterministic completion order would likely be complex and defeat the purpose of parallelism, as you noted.
However, this external nondeterminism is outside the scope of the workflow execution's determinism required for replay.
When the workflow replays, it doesn't re-run the race. It consumes events from the log. The `-await-next` operation during replay simply reads the next recorded result, based on the fixed order. Since the log provides the same sequence of results every time, the workflow's internal logic proceeds identically, making the same decisions based on that recorded history.
Determinism is maintained within the replay context by reading the persisted, ordered outcomes of those nondeterministic races.