Plugin runtime classpath during execution differs from runtime classpath during building when conflicts with test/provided scope dependencies are involved

Consider this unresolved dependency tree:

plugin
+- b:0.1:test
|  \- a:0.2:compile
\- c:0.1:compile
   +- a:0.1:compile
   \- b:0.1:compile
      \- a:0.2:compile

which resolves to

[INFO] [dependency:tree {execution: default-cli}]
[INFO] org.apache.maven.its.mng4724:maven-mng4724-plugin:maven-plugin:0.1
[INFO] +- org.apache.maven.its.mng4724:b:jar:0.1:test (scope not updated to compile)
[INFO] \- org.apache.maven.its.mng4724:c:jar:0.1:compile
[INFO]    \- org.apache.maven.its.mng4724:a:jar:0.2:compile

i.e. while building the plugin, the runtime class path consists of c-0.1.jar and a-0.2.jar.

In contrast, when executing the plugin, the resolved tree looks like

[INFO] org.apache.maven.its.mng4724:maven-mng4724-plugin:maven-plugin:0.1
[INFO] \- org.apache.maven.its.mng4724:c:jar:0.1:compile
[INFO]    +- org.apache.maven.its.mng4724:a:jar:0.1:compile
[INFO]    \- org.apache.maven.its.mng4724:b:jar:0.1:compile

i.e. b-0.1.jar is now included and instead of a-0.2.jar we get a-0.1.jar.

The cause is that in the latter case the test-scope dependency on b (and its dependency sub tree) wasn't considered at all during resolution, which hides a conflict from the process and yields a different result.

Besides the plugin class realm, this generally affects the consumption of one project by another.

IT attached, though given the apparently minor relevance for practical use and the performance loss the fix would cause, not sure we actually want to fix this...