Disclosure: I’m the executive director of CNCF, which just adopted Jaeger 2 weeks ago, and I’m an author of the landscape.
The CNCF storage WG is also looking at creating a "zoomed in" version of the storage section with higher fidelity information. That's one model of providing more detail.
We also have an interactive version of the landscape coming that will provide filtering, zooming, etc.
An analogy is SLF4J for Java logging. All libraries, etc use the same interface and the final user determines the backend: java.util, Logback. This makes sense if you have many authors of libraries with a cross-cutting concern.
This really makes OpenTracing half a dozen different standards, one per language, with common semantics.
Should it be about a wire protocol instead? Discussion at https://github.com/opentracing/specification/issues/34
There is an open issue about Envoy/linkerd/Istio support here: https://github.com/opentracing/specification/issues/86 (as well as in a number of other locations)
As an OpenTracing contributor, the core value prop still seems quite strong in that instrumentation of OSS dependencies is a massive pain point and should not be tracing-system-specific since it doesn't need to be. There is also value in common protocols and formats, and in that spirit there is interest in broadening scope to include those... though from seeing many companies adopt tracing tech, I haven't observed protocol compatibility as the main pain point or blocker.
I have no doubt that a Go tracer would start orders of magnitudes faster than a Java one (especially if it pulls in spring or other web-related dependencies for the zipkin UI) but I think it is irrelevant.