It's not clear how the arguments provided lead to the summary that extending standard attributes is a breaking change.
The discussion in the #3858 and the language used in arguments clearly tries to prevent the evolution and document the current decision, but there are no arguments that explain the breaking nature of such change.

If we want to stick to this decision in practice (i.e. as SDKs implement non-standard attributes), we need to:

• remove the "breaking change" part
• remove the The standard attribute definition SHOULD be used to represent attributes in data
  modeling unless there is a strong justification to diverge - there is no reason for Profiling to stick to standard attributes - there is no prior art in OTel that would be challenged by them
• explain the limits of this decision such as whether it applies to:
  • OTel API which should not allow complex attributes on spans/metrics API - this does not seem like a good limitation - API should not be that opinionated - that's for SDKs and backends. Moreover, several SDKs violate it already.
  • OTel SDK - API permits complex attributes, but SDK doesn't (e.g. drops them by default) - that'd be the least problematic way to keep the limitation and would still allow the evolution without requiring API v2
  • Semantic conventions - API and SDK allow end users to do anything that makes sense for them in their backend, but OTel semconv won't define complex attributes for certain signals

Having said this, I'd like to re-litigate this decision on the following grounds:

• it was driven by the desire to limit the problem space, Support maps and heterogeneous arrays as attribute values #2888 (comment)
• was based on the tracing and metrics prior art and didn't consider future problem spaces (events and correlation/consistency between signals)
• it's limiting OTel evolution and requiring hacky designs in logging SDK. We should not have a spec language that closes the door for API evolution for the sake of closing the discussion. The bar on such changes has to be extremely high.
• It goes against the spirit of Spec principles
  • Being user-driven: we see the demand for complex attributes on spans in semantic conventions. We already went far defining string formats for exception stacktraces, HTTP headers, and now we're considering JSON serialization Provide JSON String guidance for Attribute Values #4446.
  • Being consistent: we encourage recording complex values in different ways on logs and spans
  • Being simple: we complicate development experience by introducing multiple attribute types and defining conversion between them, while also assuming that this API may not be necessary in the future Attributes "hell" #4201, Introduce "extended attributes" term #4462

Relitigating this decision does not go against the values - it can be done in non-breaking manner.

The proposal would be to

• have the same attributes API on all signals
• by default SDKs would drop (or serialize to JSON) complex attributes on metrics. Users were never able to populate them, so this won't break anything existing.
• we may allow customizing this behavior and we'll pick a default (drop or serialize). We may even allow complex attributes on metrics as opt-in. This is SDK/exporter configuration.
• we'd recommend backends that don't support complex attributes on some signal to use the same default - drop or serialize at exporting or ingestion time.
• we'll restrict complex attribute usage on metrics in otel semconv via tooling/policies