Remove scope attributes form the Scope identity

Fixes #2762

The identity part can be changed later if the community agrees to accept this change, but to be safe for the moment revert this change.

Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>

specification/metrics/api.md

@@ -147,20 +147,14 @@ This API MUST accept the following parameters:
 * [since 1.13.0] `attributes` (optional): Specifies the instrumentation scope attributes
     to associate with emitted telemetry.
 
-Meters are identified by all of these parameters.
-
-Implementations MUST return different `Meter` instances when called repeatedly
-with different values of parameters. Note that always returning a new `Meter` instance
-is a valid implementation. The only exception to this rule is the no-op `Meter`:
-implementations MAY return the same instance regardless of parameter values.
-
-It is unspecified whether or under which conditions the same or different
-`Meter` instances are returned from this function when the same
-(name,version,schema_url,attributes) parameters are used.
-
-The term *identical* applied to Meters describes instances where all identifying fields
-are equal. The term *distinct* applied to Meters describes instances where at
-least one identifying field has a different value.
+Meters are identified by name, version, and schema_url fields.  When more than one
+Meter of the same `name`, `version`, and `schema_url` is created, it
+is unspecified whether or under which conditions the same or different
+`Meter` instances are returned.
+
+The term *identical* applied to Meters describes instances where all identifying
+fields are equal. The term *distinct* applied to Meters describes instances where
+at least one identifying field has a different value.
 
 Implementations MUST NOT require users to repeatedly obtain a `Meter` with
 the same identity to pick up configuration changes. This can be

specification/trace/api.md

@@ -131,23 +131,27 @@ This API MUST accept the following parameters:
 - [since 1.13.0] `attributes` (optional): Specifies the instrumentation scope attributes
   to associate with emitted telemetry.
 
-Implementations MUST return different `Tracer` instances when called repeatedly
-with different values of parameters. Note that always returning a new `Tracer` instance
-is a valid implementation. The only exception to this rule is the no-op `Tracer`:
-implementations MAY return the same instance regardless of parameter values.
+Tracers are identified by name, version, and schema_url fields.  When more than one
+Tracer of the same `name`, `version`, and `schema_url` is created, it
+is unspecified whether or under which conditions the same or different
+`Tracer` instances are returned.
+
+The term *identical* applied to Tracers describes instances where all identifying
+fields are equal. The term *distinct* applied to Tracers describes instances where at
+least one identifying field has a different value.
 
 Implementations MUST NOT require users to repeatedly obtain a `Tracer` again
-with the same name+version+schema_url+attributes to pick up configuration changes.
-This can be achieved either by allowing to work with an outdated configuration or
-by ensuring that new configuration applies also to previously returned `Tracer`s.
+with the same identity to pick up configuration changes. This can be
+achieved either by allowing to work with an outdated configuration or by
+ensuring that new configuration applies also to previously returned `Tracer`s.
 
 Note: This could, for example, be implemented by storing any mutable
 configuration in the `TracerProvider` and having `Tracer` implementation objects
 have a reference to the `TracerProvider` from which they were obtained. If
 configuration must be stored per-tracer (such as disabling a certain tracer),
-the tracer could, for example, do a look-up with its name+version+schema_url+attributes 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 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,