This makes sense as a way to define recording events as span events. Even once events are stable, there will still be cases where end users want the SDK/Collector to record events that have a span context attached as span events, so this is useful in the long term.

Even once events are stable, there will still be cases where end users want the SDK/Collector to record events that have a span context attached as span events

I was curious about this, do you have scenarios in mind where this would be helpful/needed? Thanks

Even once events are stable, there will still be cases where end users want the SDK/Collector to record events that have a span context attached as span events

I was curious about this, do you have scenarios in mind where this would be helpful/needed? Thanks

Well, we have a few places where this pattern is used already - gRPC instrumentation jumps to mind. I've personally demonstrated span events in modeling a streaming operation by creating events as part of a callback to consume data from a stream --

func readStream
   stream.on{
       data:
           span.addEvent('got data')
       complete:
           span.addEvent('done')
       error:
           span.addEvent('error', err)
    }

Even once events are stable, there will still be cases where end users want the SDK/Collector to record events that have a span context attached as span events

I was curious about this, do you have scenarios in mind where this would be helpful/needed? Thanks

Well, we have a few places where this pattern is used already - gRPC instrumentation jumps to mind

I'm hoping we can migrate gRPC semantic conventions to use (log-based) events. We discussed in semconv meeting that there should be a way for users to opt into emitting log-based events as span events in the short term until backends (e.g. Jaeger) support log-based events.

The existing span events (all but exceptions) can be mapped to log-based events without introducing event.body - they don't define any.

Based on the discussions in the Spec and Semconv WG, we'd try to leverage Event API (or log API in the short term) to emit events with body instead of adding mapping to span events.
The would help us to retire span events sooner and invest into Event API where it's lacking.

The attribute like event.data that would be essential for Event API -> log-based events mapping (if it's needed).

So I'm going to close this PR.