> I don't think A would work because the Go team has been opposed to goroutine id's, the main detractor being it would be used to create thread local storage.

> I don't think A would work because the Go team has been opposed to goroutine id's, the main detractor being it would be used to create thread local storage. I find this a weird stance. Idiomatic Go already has pervasive mutable globals, and life before main. Aside from cancelation the other thing that `context.Context` poorly abstracts is goroutine local storage. Having go routine ids and the new sync.Map seem like a backwards compatible way to add these features to go now.