What are you trying to achieve?
Propagation should follow the configuration provided to OpenTelemetry, not be dynamically influenced by external state.

Currently, the spec states that instrumentation should first evaluate x-ray propagation from the _X_AMZN_TRACE_ID environment variable before propagating the context from the lambda event.

This means that propagation could be working fine as configured, but if someone enables x-ray tracing, the resulting spans will be broken into separate traces (inconsistently depending on the x-ray sampling rate).

Options to resolve this:

• Shift responsibility for evaluating the environment variable to the x-ray propagator.
• Create a new propagator specific for evaluating the environment variable that should be configured ahead of the x-ray propagator.
• Create a new propagator that can handle both environment variable and carrier propagation appropriately that would be used for lambda instead of the current x-ray propagator. (X-ray propagator could even dynamically choose this at startup if running in a lambda environment.)
• Expose the propagation settings via API so the instrumentation can determine if x-ray propagation is being used and prioritize the environment variable propagation appropriately.
• Create a hybrid carrier in the instrumentation that prioritizes the environment variable for the x-ray specific key. This would allow existing propagators to mostly work as-is with the logic pushed into the carrier.

I'm sure there are other ideas and look forward to discussing in the SIG.

Additional context.
https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/instrumentation/aws-lambda.md#determining-the-parent-of-a-span