Need more information here about specific design problems with version ranges.
Currently, there is only one implementation of conflict resolution in Maven. In certain cases, users may wish to use alternative methods to resolve these conflicts, maybe even opting to fail the build when a conflict is detected.
These different resolution techniques may not be mapped 1:1 with a given POM. Instead, it may make more sense to allow the user to configure his own preferred strategy, in order to make his role in the development effort simpler. One such example might be QA testers, which may opt to verify that all dependencies are convergent before proceeding with what may be an irreproducible build.
It's possible for a given API to have multiple implementations. For example, the JavaMail API has the reference implementation provided by Sun, along with multiple open source versions. In many cases, POM authors will want to specify that a project depends on JavaMail, but won't necessarily want to dictate which implementation of the API is used. Moving to specification dependencies will solve this problem. The specification POM will serve as a pointer for a set of libraries which implement the API. The specification dependency would then be resolved in a number of ways, possibly with user preferences factored in via settings.xml.
Provides notation would be related to specification dependencies, but on the opposite side of the artifact relationship. For instance, Sun's JavaMail implementation would specify that it provides an implementation of the JavaMail API, as would the javamail library built by Geronimo. It would act as a reverse mapping of which API(s) are provided by a given artifact. This provides specification might need to be plural, to allow a single artifact to implement multiple APIs, thereby satisfying multiple specification dependencies from a single build.
If a user's build is broken by the most recent snapshot, rolling back would be a great option, if available.
It would be good to have a process to support releasing something into QA with the possibility of having that artifact promoted to other testing stages in binary form, or certified from RC to real release. Conversely, if a problem is found, to reverse the release progression back to SNAPSHOT status.