OK, coming in at a bit under 100 hours from when I promised this, here's the edits I'd make to the slides:

• Don't you want to use the run() function in your wrap() implementation? (Aside: rename run())
• I think mixing in the part about monkey-patching console.log is a distraction which would be better removed.
• I would replace the React Cache example with OpenTelemetry (legendecas can do this as he knows that area much better than me). Really, the OpenTelemetry case of holding a span ID instead of an initial timestamp has exactly the same needs--we should say this explicitly.
• Slide 18 is really key (maybe reference the main thread scheduling proposal? maybe not?) but the code doesn't then correspond to anything about prioritization, so it's a little confusing
• In general, let's say "async context" intead of "async stack" to reinforce the intuition around the terms. Also "stack" implies linear memory usage for the number of async items, which is definitely not the case here, but definitely is the case with general async stack traces (which is a specific non-goal here, and which we should probably avoid comparing this with in slide 19, as it will probably make browsers uncomfortable)
• All the stuff about "the dynamic scoping elephant" should be probably rephrased as "Bonus slides (if time allows): ocap analysis" and then just defer to Mark to say he thought about it and decided it's OK. I expect the committee to continue disagreeing internally on whether this deserves to be called "dynamic scoping", and really, that's all irrelevant

queueMicrotask will be handled for us once v8 fixes the current limitations

Chengzhong Wu: How is it going with proposing a meeting between us and Yoav?

Sadly, yoav hasn't responded to my email with the meeting doodle.

Justin Ridgewell: ... what's your sense on how stable the current definition of the AsyncContext interface is? Like if we were to do something silly and implement a polyfill in workerd now would we likely be shooting ourselves in the foot

I vaguely remember there used to be a set method along with get, but that's been removed… is set gone for good? (My bias: I hope so, for predictability and efficiency)

(it may be that I misunderstood/misrepresented this suggestion; corrections welcome rbuckton )

my point is, it's one of those optimizations that works best (for the implementations that choose to take advantage) if there are some restrictions in the API

(edited my text above a bit) if you ctx.run([/*mutable array*/], () => { ... }) and code within that block has access to ctx, then they can do ctx.get().push(...) as if the context value was mutable

I think of run as something you call "once per thread" (conceptually)

Do you mean the one that exists if you check the box in devtools?