The new streamed_span setter assigns self._span = span without checking what is currently stored. If the scope currently holds a Span (transaction-mode) and any caller assigns scope.streamed_span = None or a StreamedSpan, the existing Span is silently destroyed. The same asymmetry exists on the span setter for an existing StreamedSpan. Because Scope.span and Scope.streamed_span are documented as type-discriminated views over the same underlying _span, callers reasonably assume that touching one will not affect the other; this assumption does not hold and can lead to lost spans/transactions when both lifecycles are mixed.

The new code calls sentry_sdk.get_client() and has_span_streaming_enabled(client.options) outside the with capture_internal_exceptions(): block. Previously, all logic in _set_status was protected so that any internal SDK error would be swallowed. Since _set_status is invoked from _capture_exception during task error handling, an unexpected exception here (e.g., due to an uninitialized/NonRecordingClient state or a future change to has_span_streaming_enabled) would now propagate into user code rather than being captured internally, potentially masking the original task error.