## Changes

- Introduce of `AnyValue` type supporting complex data structures (empty
value, byte arrays, heterogeneous arrays and maps).
- Consolidate of attribute definitions across signals to use the unified
`AnyValue` type.
- Update attribute limits to accommodate new value types.
- Allow attribute collections to contain duplicate keys via an opt-in
configuration (as this is [allowed for log
attributes](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#type-mapstring-any)).
- Remove "standard attribute" terminology in favor of general
"attribute".

### Extend attribute types

Prior-art (this PR guides towards this):
#4636

Prototype: open-telemetry/opentelemetry-go#6809

Follows
#4614

Related to
#4602

Related proto PR:
open-telemetry/opentelemetry-proto#707


https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/4485-extending-attributes-to-support-complex-values.md#how
describes how languages should add support for new attribute value
types.

Closes
#4460
(no longer needed - feature is removed)

### OTEP changes

Notice that this PR has changed the strategy for
https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/4485-extending-attributes-to-support-complex-values.md#api
from:

> OTel API **MAY** support setting complex attributes on metrics,
resources, instrumentation scope, span events, and as identifying entity
attribute

to simply:

> OTel API **MUST** support setting complex attribute.

This is the agreement up to this point:
#4651 (comment)

The other change in the OTEP is because of
#4651 (comment).

### Attribute limit updates

Towards
#4487

This also proposes **minimal and non-breaking** additions for the
attribute limits:
https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/4485-extending-attributes-to-support-complex-values.md#attribute-limits.

The proposal for **attribute count limit** is proposed because of
#4651 (comment).

- **Predictability:** Users can more easily understand and predict when
they'll hit the limit. Especially given the existing behavior of
attribute count limit.
- **Practical usage:** Maps are typically used as cohesive units of
related data, so counting them as single attributes aligns with their
semantic purpose. Without this rule, a single map attribute with many
internal key-value pairs could quickly exhaust the attribute count
limit, which would be surprising behavior for users.

The proposal for **attribute value length limit** seems the most logical
to me.

## Comments to be addressed as followups

I am going to create issues to be created after this is PR merged:

-
#4651 (comment)
-
#4651 (comment)
-
#4651 (comment)

---------

Co-authored-by: Tyler Yahn <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Liudmila Molkova <[email protected]>
Co-authored-by: Martin Costello <[email protected]>