BatchSpanProcessor export timeout configuration transition and span-drop reporting gap

OpenTelemetry's BatchSpanProcessor exports spans on a configurable schedule, passing a context equipped with an export timeout to downstream exporters such as OTLP. When the deadline elapses, in-flight export work is abandoned and buffered spans may be dropped rather than retried indefinitely. A precise goal for this investigation is to determine whether spans lost due to export timeout are reported to the application's error handler, logged silently, or counted as metrics across the supported SDK languages. The documented timeout propagation through forceFlush and shutdown paths, combined with the OTLP exporter's OTEL_EXPORTER_OTLP_TIMEOUT setting, establishes a per-export deadline that interacts with context cancellation during shutdown. However, no cross-language specification guarantees the reporting fate of dropped spans, and default timeout values and retry backoff behavior differ between Java, Go, Python and JavaScript runtimes. Teams deploying bounded shutdown contexts must therefore decide their own observability strategy for export loss.

• Does the SDK or exporter surface a countable event when spans are discarded because the export deadline expires?
• Is the drop communicated through the application's error handling pipeline, or is it confined to internal SDK logging?
• How do differing default timeout values across SDK versions affect the reliability of graceful shutdown in containerized environments?