Clarify possibility to extend SDK interfaces

CHANGELOG.md

@@ -92,6 +92,9 @@ release.
 
 ### Supplementary Guidelines
 
+- Clarify that it is permissible to extend SDK interfaces without requiring a new major version
+  ([#4030](https://github.com/open-telemetry/opentelemetry-specification/pull/4030))
+
 ## v1.32.0 (2024-04-11)
 
 ### Context

specification/versioning-and-stability.md

@@ -12,8 +12,8 @@
   * [Experimental](#experimental)
   * [Stable](#stable)
     + [API Stability](#api-stability)
-      - [Extending Existing API Calls](#extending-existing-api-calls)
     + [SDK Stability](#sdk-stability)
+    + [Extending API/SDK abstractions](#extending-apisdk-abstractions)
     + [Contrib Stability](#contrib-stability)
     + [Semantic Conventions Stability](#semantic-conventions-stability)
     + [Telemetry Stability](#telemetry-stability)
@@ -104,13 +104,22 @@ All existing API calls MUST continue to compile and function against all future
 
 Languages which ship binary artifacts SHOULD offer [ABI compatibility](glossary.md#abi-compatibility) for API packages.
 
-##### Extending Existing API Calls
+#### SDK Stability
+
+Public portions of SDK packages MUST remain backwards compatible.
+There are two categories of public features: **plugin interfaces** and **constructors**.
+Examples of plugins include the SpanProcessor, Exporter, and Sampler interfaces.
+Examples of constructors include configuration objects, environment variables, and SDK builders.
+
+Languages which ship binary artifacts SHOULD offer [ABI compatibility](glossary.md#abi-compatibility) for SDK packages.
 
-An existing API call MAY be extended without incrementing the major version
+#### Extending API/SDK abstractions
+
+An existing API/SDK call MAY be extended without incrementing the major version
 number if the particular language allows to do it in a backward-compatible
 manner.
 
-To add a new parameter to an existing API call depending on the language several
+To add a new parameter to an existing API/SDK call depending on the language several
 approaches are possible:
 
 - Add a new optional parameter to existing methods. This may not be the right
@@ -121,18 +130,18 @@ approaches are possible:
   include the new parameter. This is likely the preferred approach for languages
   where method overloads are possible.
 
-There may be other ways to extend existing APIs in non-breaking manner. Language
+Similarly, existing SDK plugin interfaces MAY be extended with new methods without incrementing the major version
+number if the particular language allows to do it in a backward-compatible
+manner (e.g. by providing default implementations). Hereby, backwards-compatible means that end user's code that implements
+the plugin interfaces MUST continue to be possible to use with newer versions of the SDK without making changes to the end user's code.
+If this backwards compatible addition of methods to interfaces is not possible for a language,
+the language maintainers MAY still implement the addition using backwards-compatible workarounds without incrementing the major version.
+For example, a possible workaround might be to add a new interface instead of extending the existing one and accepting the
+new interface in addition to the old one in every place.
+
+There may be other ways to extend existing API/SDKs in non-breaking manner. Language
 maintainers SHOULD choose the idiomatic way for their language.
 
-#### SDK Stability
-
-Public portions of SDK packages MUST remain backwards compatible.
-There are two categories of public features: **plugin interfaces** and **constructors**.
-Examples of plugins include the SpanProcessor, Exporter, and Sampler interfaces.
-Examples of constructors include configuration objects, environment variables, and SDK builders.
-
-Languages which ship binary artifacts SHOULD offer [ABI compatibility](glossary.md#abi-compatibility) for SDK packages.
-
 #### Contrib Stability
 
 Plugins, instrumentation, and other contrib packages SHOULD be kept up to date