Should OpenTelemetry expose a dedicated API for configuring per-span timeouts instead of relying only on context propagation?

Determine whether OpenTelemetry should provide a dedicated API for configuring timeouts on individual spans, rather than relying exclusively on context‑propagated deadlines.

The specification leaves the exact moment a span is considered “ended” versus “aborted” to each SDK implementation, leading to differences in recorded duration and attributes after a cancellation or timeout. This variability, combined with an open debate about exposing a per‑span timeout method in the latest spec (v1.28), raises questions about backward compatibility, usability, and trace consistency.

Should the SDK expose a SetTimeout‑like method on Span objects? How would such an API interact with existing context deadlines without causing conflicts? What impact would it have on existing instrumentation and the uniformity of trace data across language SDKs?