Clarify that metric advice is non-identifying (#3661)

Fixes
#3622

The language for resolving conflicts matches the language used for
naming conflicts.

cc @MrAlias @jack-berg @jmacd

CHANGELOG.md

@@ -21,6 +21,8 @@ release.
   ([#3242](https://github.com/open-telemetry/opentelemetry-specification/pull/3242))
 - Promote MetricProducer specification to feature-freeze.
   ([#3600](https://github.com/open-telemetry/opentelemetry-specification/pull/3600))
+- Clarify that advice is non-identifying.
+  ([#3661](https://github.com/open-telemetry/opentelemetry-specification/pull/3661))
 
 ### Logs
 

specification/metrics/api.md

@@ -190,7 +190,7 @@ will have the following fields:
 * Optional `advice` (**experimental**)
 
 Instruments are associated with the Meter during creation. Instruments
-are identified by all of these fields.
+are identified by the `name`, `kind`, `unit`, and `description`.
 
 Language-level features such as the distinction between integer and
 floating point numbers SHOULD be considered as identifying.

specification/metrics/sdk.md

@@ -856,6 +856,11 @@ When a Meter creates an instrument, it SHOULD validate the instrument advice
 parameters. If an advice parameter is not valid, the Meter SHOULD emit an error
 notifying the user and proceed as if the parameter was not provided.
 
+If multiple [identical Instruments](api.md#instrument) are created with
+different advice parameters, the Meter MUST return an instrument using the
+first-seen advice parameters and log an appropriate error as described in
+[duplicate instrument registrations](#duplicate-instrument-registration).
+
 ## Attribute limits
 
 **Status**: [Stable](../document-status.md)