`@added` and shared header name but added in different versions.

[jeremymeng]

from the discussion at https://github.com/Azure/azure-rest-api-specs/pull/45405/changes#r3760998866

I refactor some inline header into an alias so that I can customize the prorperty name for JS client. in this case of Storage Blob, the same header "x-ms-content-crc64" was added to different models in different service versions. Some locations have the @added decorator but other locations don't. I had to add one alias for each, because the @added decorator is attached to the property, and had to customize all of these aliases.

https://github.com/Azure/azure-rest-api-specs/pull/45405/changes#diff-d82d8650dde4a68fe127b0c2c713ab7072ae36a3b60d5f424941464da18abe5dR1653

Could there be a better way?

[github-actions]

🎯 Issue Triage

A feature request for better ergonomics when the same header (e.g., x-ms-content-crc64) is added in different service versions across multiple models — currently requiring one alias per version/location due to @added being attached to individual properties.

Category: Feature Request

Area: lib:versioning

🔍 Analysis

The user needs to share a header alias across multiple models but some instances have @added(v2) and others don't. Since @added is scoped to the property (not the alias), they're forced to create separate aliases for each variant — defeating the purpose of refactoring into an alias.

A potential improvement would be allowing @added to be applied at the alias level or supporting some way to conditionally include a shared type alias based on version context, reducing the duplication burden.

Affected area: @typespec/versioning library — specifically how @added interacts with type aliases used as shared header definitions.

📝 Suggested next steps

• Design a mechanism to allow version decorators (like @added) to work with shared type aliases, or provide a way to compose versioned aliases more cleanly
• Consider whether this is feasible at the compiler level or as a versioning library enhancement
• Link to relevant Azure REST API specs PR for context: [storage-blob] JS rename of contentCrc64 => xMsContentCrc64 and accessTierChangeTime => accessTierChangedOn Azure/azure-rest-api-specs#45405

Generated by Agentic Triage