Well of course we have people saying "if you need this feature, you're doing it wrong"... so ok, if a huge number of us maintaining projects in the real world are "doing it wrong", let's discuss how to do it right for a very specific, concrete use case:
Now first, don't get me wrong, I agree with this statement: If there's a need for a global exclusion, SOMEONE most likely did SOMETHING wrong. The problem is, "someone" isn't always the group that needs the exclusion, and "something" isn't always under that group's control.
I've found it's very common that an artifact started out with one groupId and later switched to another groupId. Often this is because the original groupId was not good - like we could talk about stax:stax-api:1.0
But even if the original groupId was a nice "inverted domain"-prefixed identifier, maybe maintenance of the artifact changes hands and the new folks switch to THEIR domain. Whatever. The point is, maven doesn't recognize new.group:artifact:2.0 as conflicting with old.group:artifact:1.0
Now, did SOMEONE do SOMETHING wrong? Sure, I won't argue about that. But I still have to write a pom that says "I'm using javax.xml.stream:stax-api:1.1 and I don't need/want/have the luxury to tolerate stax:stax-api:1.0 on my classpath"; I'd rather that did not turn into a game of whack-a-mole.
So, you prefer to provide an artifact aliasing mechanism of some sort instead of global exclusions? Cool, that idea's apparently been under discussion for years; so if you ACTUALLY PROVIDE IT then I'll accept it as a counter to my claim that I need a global exclusion.
So, have I missed a feature, or are all the explanations of what I should do to solve this problem just talk that I can't use?