Major Description
In Maven3 this was not a problem, as Maven3 could add depMgt only on "root level".
In Maven4 with use of new/old transitive Dependency Managers this became a problem. The dependency manager first receives depMgt entries for currently processed node, and then applies it onto same entry, overriding direct dependency versions.
Example with Maven beta-5: it cannot build Resolver master (88a96ac0606d4d2372452a677d9f93c0b55105a4) as bnd-maven-plugin do depend on plexus-utils via path of bnd-maven-plugin > build-api > plexus-utils as it explodes due lack of org.plexus.utils.Scanner on classpath. This class was introduced in plexus-utils 1.5.8, and build-api do depend on it. But alas, build-api parent contains depMgt entry for plexus-utils 1.5.5 and is applied onto build-api overriding it's own dependency version.
Basically current resolver code is NOT prepared for any "transitive dependency management" (despite DependencyManagers are there) as node would apply it's own depManagement rules onto itself.