I think that's a rather personal point of view, if you don't mind me saying. On that basis, none of us would make use of AspectJ or proxies.
It is already the case that a child project configured to download X gets Y, as that's what we're actually trying to do. The problem is that it doesn't actually say "replace X with Y". It says: "don't download X".
You are mistaken in thinking that "when I look at the child POM, it says download X" is relevant to what we as developers need. We can easily end up with multiple versions of the same API on the classpath because the exclusions weren't set on every child.
At some point in our project we want to say something like (as OSGi gives us): the implementation of org.apache.commons.logging that I want to use in my build and runtime can be found in org.slf4j:slf4j:org.apache.commons.logging, or, if we want one that has been built as a valid OSGi bundle: org.slf4j:com.springsource.slf4j.org.apache.commons.logging.
What we certainly don't want is to have to repeat the exclude on an ad-hoc basis, and nor do we want the meaning lost in separating out an exclusion with a global inclusion (which is not always wanted either - e.g. for corporate standards).
Can you please tell me how you propose to satisfy this use case, if you still have your objections to my solution. It's all very well disagreeing, but it would be useful to offer a better solution in it's place.