If a goroutine already exists at the start of an execution trace, e.g. it's been blocked since the trace started, we don't get a call stack for the first event recorded for the goroutine. If the goroutine stays blocked for the entire trace, we get no call stacks at all and have no way to identify the goroutine.

The previous tracer implementation recorded the starting PC for a goroutine as a one-frame "call stack" when enumerating the goroutines which exist at the start of the trace. The v2 tracer lost this behavior. We could bring it back, or, as @mknyszek suggested in #65574:

I think instead of taking a PC though, we should consider taking the full stack trace. The tracer takes ownership of the goroutine when it reads its status for the case where a goroutine is waiting or in a syscall for an entire generation.GoStatus events will just have an additional stack argument (usually 0, unless it falls into one of these cases). We would have to take and store the stack here: https://cs.opensource.google/go/go/+/master:src/runtime/trace2.go;l=336?q=trace2.go&ss=go%2Fgo:src%2Fruntime%2F. We then emit the stack later, if it turns out we're going to emit a GoStatus event for the goroutine.

I'm +1 on this idea. If a goroutine is blocked for the duration of a trace, it would be helpful to know where it's blocked.