@customAzureResource doesn't work as expected

[pshao25]

Take trafficmanager as example, this resource extends Resource which has non-readonly id, name, type.

We had several trials.
Option 1: Extends ProxyResource from library.

1. It's breaking change.
2. This changes non-readonly id, name, type to readonly. Therefore it fails Model Validation https://github.com/Azure/azure-rest-api-specs/actions/runs/18671861311

Option 2: Defined customized ProxyResource without name (playground)

The route doesn't have name parameter, isn't expected.

Option 3: Defined customized ProxyResource with name (playground)

The get operation is expected, but create operation doesn't have expected route.

[markcowl]

It is expected that you cannot repeat the name parameter and use it with customAzureResource, this requires additional (private) decoration, or it can be used with legacy templates. If we need to be able to write resources that look like resources that use common-types, but differ by optionality/readOnly, then we can do this, but this seems to be perpetuating incorrectness in the spec, since changing the name, id, or type of a resource seems not to make sense.

My suggestion would be to use option 1, as this seems to be actually correct

[markcowl]

Hmm, looking at the spec, it appears that at least resource type might be settable. interesting, and because they identified this as a proxy resource, it is possible. Because the 'name' property is special for resources, and the name property must be readOnly in order to not conflict with the resource name parameter, I think we would need to use legacy templates for this resource.

[pshao25]

Next action:
Pan reaches to service team to confirm the expected behavior.