Make schema_url part of Tracer/Meter identity

specification/metrics/api.md

@@ -140,16 +140,16 @@ It is unspecified whether or under which conditions the same or different
 `Meter` instances are returned from this functions.
 
 Implementations MUST NOT require users to repeatedly obtain a `Meter` again with
-the same name+version 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 `Meter`s.
+the same name+version+schema_url 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 `Meter`s.
 
 Note: This could, for example, be implemented by storing any mutable
 configuration in the `MeterProvider` and having `Meter` implementation objects
 have a reference to the `MeterProvider` from which they were obtained. If
 configuration must be stored per-meter (such as disabling a certain meter), the
-meter could, for example, do a look-up with its name+version in a map in the
-`MeterProvider`, or the `MeterProvider` could maintain a registry of all
+meter could, for example, do a look-up with its name+version+schema_url in a map
+in the `MeterProvider`, or the `MeterProvider` could maintain a registry of all
 returned `Meter`s and actively update their configuration if it changes.
 
 The effect of associating a Schema URL with a `Meter` MUST be that the telemetry

specification/trace/api.md

@@ -125,17 +125,17 @@ It is unspecified whether or under which conditions the same or different
 `Tracer` instances are returned from this functions.
 
 Implementations MUST NOT require users to repeatedly obtain a `Tracer` again
-with the same name+version to pick up configuration changes.
+with the same name+version+schema_url 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 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.
+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 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,