Per opentracing/opentracing-cpp#3 as well as numerous misc discussions on Gitter.

Basically, most OT implementations have some sort of trace_id under the hood. There is practical value in exposing that, but there are also immediate problems:

1. There is nothing in the OT spec about any particular sort of "id" (trace, span, or otherwise); and even if there were, there is no way for OT to know the bitwidth of those ids or even whether they're strings/ints/whatever.
2. Since the OT spec allows for multiple parent spans, the "trace id" (sic) is not actually a single id / is not well-defined across the trace.

One option would be a SpanContext.DebugCorrelationID that would return a string and be a sort of "best-effort trace_id" for lack of a better word. I have mixed feelings about this but wanted to raise it for discussion and tracking.