I agree, I think <exclude> functionality would be a big help. I've encountered this problem in another way, and that is working with MyEclipse and JBoss.
To be able to build my web apps successfully with Maven alone, I make reference to the needed Java EE api's with provided scope. When I run mvn eclipse:eclipse to work with MyEclipse however, I've added additional <classpathContainer> settings for MyEclipse's "com.genuitec.eclipse.j2eedt.core.J2EE14_CONTAINER". This means within MyEclipse, my application has a reference to the needed JEE classes from MyEclipse's container settings, and from my "provided" scope JEE dependencies. Not a huge problem, until I use MyEclipse's integration with JBoss. JBoss 4.2.0 with blow up because the JEE dependencies are deployed with the app to JBoss from MyEclipse (whereas MyEclipse J2EE14_CONTAINER isn't, as MyEclipse knows not to do this).
So, to sum up - our production builds are created using a continuous integration server with Maven, meaning the JEE dependencies have to be made available with our app, but having this dependency added to the .classpath file for MyEclipse use actually gets in the way of MyEclipse's custom com.genuitec.eclipse.j2eedt.core.J2EE14_CONTAINER. All of this could be avoided with some kind of dependency exclusion filter when generating the .classpath file (similiar to the patch supplied). This way Maven can keep the dependencies it needs, but Eclipse dependency use can be modified when needed.
Thanks very much!