Define how providers handle identical creation calls

CHANGELOG.md

@@ -11,10 +11,19 @@ release.
 
 ### Traces
 
+- Define how `TracerProvider` handles identical `Tracer` creation calls.
+  ([#4146](https://github.com/open-telemetry/opentelemetry-specification/pull/4146))
+
 ### Metrics
 
+- Define how `MeterProvider` handles identical `Meter` creation calls.
+  ([#4146](https://github.com/open-telemetry/opentelemetry-specification/pull/4146))
+
 ### Logs
 
+- Define how `LoggerProvider` handles identical `Logger` creation calls.
+  ([#4146](https://github.com/open-telemetry/opentelemetry-specification/pull/4146))
+
 ### Events
 
 ### Resource

specification/logs/bridge-api.md

@@ -95,9 +95,10 @@ The term *identical* applied to `Logger`s describes instances where all
 identifying fields are equal. The term *distinct* applied to `Logger`s describes
 instances where at least one identifying field has a different value.
 
-The effect of associating a Schema URL with a `Logger` MUST be that the telemetry
-emitted using the `Logger` will be associated with the Schema URL, provided that
-the emitted data format is capable of representing such association.
+The effect of associating a Schema URL and instrumentation scope attributes with
+a `Logger` MUST be that the telemetry emitted using the `Logger` will be
+associated with the Schema URL and instrumentation scope attributes, provided
+that the emitted data format is capable of representing such association.
 
 ## Logger
 

specification/logs/sdk.md

@@ -67,6 +67,11 @@ The input provided by the user MUST be used to create
 an [`InstrumentationScope`](../glossary.md#instrumentation-scope) instance which
 is stored on the created `Logger`.
 
+The method MUST return the same instance when the caller requests _identical_
+`Logger`s. In such scenario, the returned `Logger` MUST have the non-identifying
+fields' values (e.g. instrumentation scope attributes) assigned during the first
+_identical_ `Logger` creation call.
+
 In the case where an invalid `name` (null or empty string) is specified, a
 working `Logger` MUST be returned as a fallback rather than returning null or
 throwing an exception, its `name` SHOULD keep the original invalid value, and a

specification/metrics/sdk.md

@@ -123,13 +123,19 @@ The input provided by the user MUST be used to create
 an [`InstrumentationScope`](../glossary.md#instrumentation-scope) instance which
 is stored on the created `Meter`.
 
+The method MUST return the same instance when the caller requests _identical_
+`Meter`s. In such scenario, the returned `Meter` MUST have the non-identifying
+fields' values (e.g. instrumentation scope attributes) assigned during the first
+_identical_ `Meter` creation call.
+
 In the case where an invalid `name` (null or empty string) is specified, a
 working Meter MUST be returned as a fallback rather than returning null or
 throwing an exception, its `name` SHOULD keep the original invalid value, and a
 message reporting that the specified value is invalid SHOULD be logged.
 
-When a Schema URL is passed as an argument when creating a `Meter` the emitted
-telemetry for that `Meter` MUST be associated with the Schema URL, provided
+When a Schema URL and instrumentation scope attributes are passed as an argument
+when creating a `Meter` the emitted telemetry for that `Meter` MUST be
+associated with the Schema URL and instrumentation scope attributes, provided
 that the emitted data format is capable of representing such association.
 
 **Status**: [Development](../document-status.md) - The `MeterProvider` MUST

specification/trace/api.md

@@ -161,10 +161,10 @@ the tracer could, for example, do a look-up with its identity in a map
 in the `TracerProvider`, or the `TracerProvider` could maintain a registry of
 all returned `Tracer`s and actively update their configuration if it changes.
 
-The effect of associating a Schema URL with a `Tracer` MUST be that the
-telemetry emitted using the `Tracer` will be associated with the Schema URL,
-provided that the emitted data format is capable of representing such
-association.
+The effect of associating a Schema URL and instrumentation scope attributes with
+a `Tracer` MUST be that the telemetry emitted using the `Tracer` will be
+associated with the Schema URL and instrumentation scope attributes, provided
+that the emitted data format is capable of representing such association.
 
 ## Context Interaction
 

specification/trace/sdk.md

@@ -71,6 +71,11 @@ The input provided by the user MUST be used to create
 an [`InstrumentationScope`](../glossary.md#instrumentation-scope) instance which
 is stored on the created `Tracer`.
 
+The method MUST return the same instance when the caller requests _identical_
+`Tracer`s. In such scenario, the returned `Tracer` MUST have the non-identifying
+fields' values (e.g. instrumentation scope attributes) assigned during the first
+_identical_ `Tracer` creation call.
+
 **Status**: [Development](../document-status.md) - The `TracerProvider` MUST
 compute the relevant [TracerConfig](#tracerconfig) using the
 configured [TracerConfigurator](#tracerconfigurator), and create
@@ -236,7 +241,7 @@ Thus, the SDK specification defines sets of possible requirements for
   both the full span API as defined in the
   [API-level definition for span's interface](api.md#span-operations) and
   additionally must be able to retrieve all information that was added to the span
-  (as with *readable span*).
+  (as with _readable span_).
 
   It MUST be possible for functions being called with this
   to somehow obtain the same `Span` instance and type