What

When `OTEL_CONFIG_FILE` is set, `_OTelSDKConfigurator._configure` returns before calling `initialize_components`, so all `OTEL_PYTHON*` environment variables are silently bypassed. Examples:

• `OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED` — no effect; the logging handler is not set up.
• `OTEL_PYTHON_TRACER_PROVIDER` / `OTEL_PYTHON_METER_PROVIDER` / `OTEL_PYTHON_LOGGER_CONFIGURATOR` etc. — same.

The `OTEL_CONFIG_FILE` docstring (added in #5271) only speaks to spec-defined `OTEL_` variables with schema equivalents. `OTEL_PYTHON_` are Python-implementation extensions, not in the spec, and have no equivalents in the schema.

Question

Two reasonable behaviours, picking one is a design call:

1. Bypass them (current behaviour). Document as a known limitation. Users who need an `OTEL_PYTHON_*` extension cannot use `OTEL_CONFIG_FILE`.
2. Honor them alongside the file. Read `OTEL_PYTHON_*` separately (or pass-through through `_initialize_components`-equivalent code) so the file controls SDK construction but Python-specific extensions still apply.

Option 2 may overlap with the Phase 2 env-var-to-config adapter (#5126) — those Python-specific knobs could land as schema additions instead.

Outcome

A decision and either:

• a docstring/README update calling out current behaviour as intentional, or
• a small wiring PR that honors the relevant `OTEL_PYTHON_*` extensions when the file is set.

Refs #3631
Refs #5126