A single promise could be branched multiple times, and unhandledrejection events are dispatched for each "unhandled" promise, rather than a single source of rejection

the way I think of it, if an exception (or promise rejection) is "automatically rethrown" (as might happen conceptually in run), then if you have a way to act on that error, then that context shouldn't be lost without a trace

I don't think this is a problem. Context splits are not problematic, only merges are. If you only care about one of the branched promises but not the rest, you could still want to know the source of rejection

I think the flow-through pattern doesn't answer the similar problem of https://github.com/tc39/proposal-async-context/issues/90.

The originating context could be a stack of contexts and use inner-most context would discard all outer contexts. Each await creates resolution handler on a potentially rejected promise, use the inner-most context would lose the context when the rejection was handled multiple times.

let aGlobalPromise = asyncVar.run('global', () => {
  return Promise.reject()
})

async function someAsyncApi() {
  await asyncVar.run('async-inner', async () => {
    try {
      await aGlobalPromise
    } catch (e) {
      throw e
    }
  })
}

asyncVar.run("foo", async () => {
  await someAsyncApi()
});
asyncVar.run("bar", async () => {
  await someAsyncApi()
});

window.addEventListener("unhandledrejection", () => {
  console.log(asyncVar.get());  // 'foo' or 'bar' or 'global' or 'async-inner'?
});

but maybe the context would be propagated properly through the chain of rejections?

but it's looking like with the current spec, someAsyncApi().then() would lose track of the rejection context