Is the trace on event handler agnostic to event types? In implementations where instrument known event types, it can determine either creating a new root span, or creating a child span by event type semantics.

Whether it is event-specific determines whether we could indicate important context in event-specific properties, as you had proposed, and have a bit of logic to fix things up with that information

I think the difficulty here is two-fold: both third-party libraries and distant first-party developers are doing async things (e.g. listening on events, etc) on their own terms and in their own ways, and it's not reasonable to expect them to know whether and when they need to do special handling to propagate a non-default context, and there's no good way for the framework that cares about that propagation to stick itself in the way to make it happen the right way. This is independent of any event type, and (as far as I can tell at first glance) seems to require that we pick the "right default" from the start, since any incorrect default will break the flow.

This is a lot of upfront work, but may not be infeasible. There's a large but finite number of events to consider, and a divide-and-conquer approach may make it possible within a few months...? I agree that changing this in the future is likely to be problematic, unless we could reasonably poison the context of not-yet-decided events, but I'm having trouble imagining how that could work reasonably.