Andreu Botella

> I'm confused. The run aspect of the example isn't the concern; it's creating a new Variable instance on every request. Per the OP, each request then inserts a key...

One of the possibilities for the web integration of AsyncContext is that script-triggered same-origin navigations would use the context in which you start the navigation (e.g. where you set `location.href`)...

> My thinking with context runs has always been to treat it like a special case of function call/apply. For what's worth, my feeling is that most non-APM uses of...

After some discussion in today's meeting, it was pointed out that when you need the originating context for an event, you usually want to choose which context to use when...

> There is always a valid originating context, it's just not necessarily directly synchronously calling the continuation. That is not the case. In the browser, a user-initiated click event does...

> Which context is used at the beginning of the main script? The/An empty context or something else? If it is an empty context it would be also propagated into...

> The originating context of a click would be the setting up of a system to track clicks, which would be the page loading in the first place and therefore...

> I've got one more example of how this could mesh with a Web API that was passed over: There's a spec being worked on for [signals](https://github.com/tc39/proposal-signals) (i.e. computed and...

Since I opened this issue, I noticed a couple cases that I missed in my analysis: - As a result of the conversation in #83, I started thinking about the...

I'm considering whether it would not be better to use the originating context by default for events, rather than the registration context. If we do this, there wouldn't be any...