Breaking change in 1.40 to Tracer/Span behavior in opentelemetry-api not documented

PR https://github.com/open-telemetry/opentelemetry-python/pull/4861 involved breaking changes to fundamental behavior of the opentelemetry-api package, namely the Span/Tracer behavior that IIUC should be stable. Mainly the span context can differ in cases where it was previously the invalid (all-zero) span context, which may also lead to differing extract/inject behavior. E.g. a service that previously did not propagate any trace/span ID from incoming to outgoing request might now do so.
But there are also more subtle differences that might break code that e.g. relied on identity checks for INVALID_SPAN (e.g. https://github.com/open-telemetry/opentelemetry-python-contrib/blob/242cfe1c58d6896144d75c404a4784d4bd16cfed/opentelemetry-instrumentation/src/opentelemetry/instrumentation/utils.py#L152, not that I can think of any likely scenario where this one would actually be hit).

So I don't want to say that it requires a major version bump (although I also don't want to say it wouldn't make sense), but it should IMHO at least be documented more clearly in release notes.

Maybe these changes were even all unintentional, then maybe it still makes sense to revert them, as the main feature that the PR was meant to implement is only experimental.

Start by reviewing PR 4861 and the opentelemetry-api Span/Tracer behavior it changed. Check the release-note documentation and the referenced instrumentation/utils.py identity check, then document the changes to span context and extract/inject behavior, including whether the behavior is intentional. Done means the relevant 1.40 breaking changes and their practical impact are clearly recorded.