Robert Pająk

> This workflow is minimally different than simply having separate config files Alternatively `OTEL_CONFIG_FILE` env var might need to support multiple file paths. How will we define that a provider...

> Multiple tracer providers in one file requires that they be named / identified and that the caller has some way to obtain the instance they want. 1. The names/IDs...

> The spec says it should be possible to create multiple providers, but doesn't give any mechanism for identifying these providers or automatically configuring them. That's new to this proposal....

Personally, I do not want to propose not decide "how" to do it. My proposals were just "drafts" to "visualize" the issue. First of all, we should decide if this...

> The example above can return multiple Configuration Models from the same file using multiple YAML documents will work and gives the same index based access returning multiple providers from...

> Do you mean allow multiple providers be defined with a distinct name / ID, then when configuring users of providers (eg instrumentation libraries) you can provide the name /...

Why not having semantic conventions for each runtime/language instead? E.g. `jvm.thread.id`, `jvm.thread.name` for Java, `go.goroutine.id` for Go, `python.asynciotask.name` for Python, etc. I would leave `thread.id` and `thread.name` for OS thread...

The env var should have a `OTEL_DOTNET_` prefix. Reference https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/#language-specific-environment-variables

> I will try to make this as a shared go template file so `otlploghttp` can use a shared logic with `otlploggrpc` in the following PRs. Keep in mind that...

@bagmeg, sure