Thanks for the PR, see discussion in #41188

As explained in #41188, we'd also need a collision-detection-and-resolution mechanism, whatever the resolution algo, which we need to design.

As explained in #41188, we'd also need a collision-detection-and-resolution mechanism, whatever the resolution algo, which we need to design.

@nicolas-grekas Currently an exception is thrown if the alias is already in use, with a message that points to the service using it. But now that I think about it, this wouldn't work if a vendor service used the attribute, since you wouldn't be able to change that.

I'm guessing one way of doing it is to keep the current behavior and just let next definition overwrite the previous one?

Thanks for the PR.
I'm not really convinced this provides a real benefit over configuration.
The reason is that configuration is centralized so that it's easy to know where to check for aliases. But on a class, this can be at a random location. Also, the conflicts might be confusing and I don't think we can define a behavior that makes them go away.

@nicolas-grekas Thanks for the feedback, your point is valid, it could be hard to find which class has this attribute, having it in a config file is probably better. If it's ok wit you I'll close this PR .

Let's close, thanks for giving this a try!

See #49361