Per a discussion with @PhilMiller, we've concluded that a mechanism that actually holds back messages for a given collective step (from one chain to another) could provide a clearer semantic.

First, note that a message marked with a collective epoch could arrive before that epoch is even created on another node. This is because theTerm()->makeCollectiveEpoch(..) is not synchronized by design. This definitely complicates any mechanism that we build.

My current proposition:

1. Add a bit to epoch that indicates if the epoch is ready to execute immediately or must be made ready. Currently, all are ready immediately.

2. If that bit is set as unready, the virtual context collection manager will not deliver the message until the user indicates it ready.

3. Add a call proxy(idx).ready(epoch) that allows delivery

4. Add the proxy to collection chain set so it can call this, for each index at the right time, and set the epoch bit appropriately.