So if context always flows into all branches, all we actually need is the context as it was when it reached a merge barrier. For example, context flows into each of the promise-returning functions passed into a Promise.all(...). Each of these branches can change their context along the path but will only ever have one value. When the value eventually reaches the merge barrier where it would get placed in the array the Promise.all(...) call resolves to it would capture the single context value in that branch and store it in a merge context array of equal length to the Promise.all(...) input and output size.

The resulting merge context makes the most sense though if the resolve path is followed rather than the register path. If the register path is followed it just flattens same as the async/await issue I brought up, which means none of that merge context would reach anywhere useful if the register on the Promise.all(...) discards all that inner behaviour by binding around it. This is the sort of scenario why I want to have a way to get at calling context whenever a snapshot is restored. Either that or have a way to, on a per-store basis, reject the snapshot restore decision and keep using the value that propagated through the internal branch.

Merge contexts are a bit weird though as it transforms a single value into an array of values, so I think it still makes sense to "pick a winner" for the default behaviour and just provide power users an additional power tool there, which might require a bit more manual intervention, to get at the full merge context list.

While thinking about the rejection context of web APIs that take async callbacks, I realized that if you do something like this, there's no way to preserve the original rejection context even if you explicitly want to:

asyncCb().catch(err => {
    if (something(err)) {
        return someValue;
    } else {
        throw err;
    }
});