diff --git a/CHANGELOG.md b/CHANGELOG.md
index 170abe2fc4c..4a4ba583f0f 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -13,6 +13,9 @@ release.
 
 ### Metrics
 
+- Clarify SDK behavior when view conflicts are present
+  ([#2462](https://github.com/open-telemetry/opentelemetry-specification/pull/2462)).
+
 ### Logs
 
 ### Resource
diff --git a/specification/metrics/sdk.md b/specification/metrics/sdk.md
index 5f587cdb666..e040fabeece 100644
--- a/specification/metrics/sdk.md
+++ b/specification/metrics/sdk.md
@@ -195,8 +195,10 @@ In order to avoid conflicts, views which specify a name SHOULD have an
 instrument selector that selects at most one instrument. For the registration
 mechanism described above, where selection is provided via configuration, the
 SDK SHOULD NOT allow Views with a specified name to be declared with instrument
-selectors that may select more than one instrument (e.g. wild card instrument name)
-in the same Meter.
+selectors that may select more than one instrument (e.g. wild card instrument
+name) in the same Meter. For this and other cases where registering a view will
+cause a conflict, SDKs MAY fail fast in accordance with
+initialization [error handling principles](../error-handling.md#basic-error-handling-principles).
 
 The SDK SHOULD use the following logic to determine how to process Measurements
 made with an Instrument:
@@ -209,11 +211,14 @@ made with an Instrument:
 * If the `MeterProvider` has one or more `View`(s) registered:
   * For each View, if the Instrument could match the instrument selection
     criteria:
-    * Try to apply the View configuration. If there is an error or a conflict
-      (e.g. the View requires to export the metrics using a certain name, but
-      the name is already used by another View), provide a way to let the user
-      know (e.g. expose
-      [self-diagnostics logs](../error-handling.md#self-diagnostics)).
+    * Try to apply the View configuration. If applying the View results
+      in [conflicting metric identities](./datamodel.md#opentelemetry-protocol-data-model-producer-recommendations)
+      the implementation SHOULD apply the View and emit a warning. If it is not
+      possible to apply the View without producing semantic errors (e.g. the
+      View sets an asynchronous instrument to use
+      the [Explicit bucket histogram aggregation](#explicit-bucket-histogram-aggregation))
+      the implementation SHOULD emit a warning and proceed as if the View did
+      not exist.
   * If the Instrument could not match with any of the registered `View`(s), the
     SDK SHOULD enable the instrument using the default aggregation and temporality.
     Users can configure match-all Views using [Drop aggregation](#drop-aggregation)