Thanks for the detailed test cases Detelin.

The fundamental issue here is that Gradle currently has no concept of the 'newest' version of a changing module. So Gradle is unable to find the 'newest' version of a changing module across multiple repositories, which is what you require.

When Gradle resolves a dependency, it iterates over the list of repositories until it finds a match. The first matched module is used, and subsequent repositories are not searched. This is true also for changing modules: we will check in repositories for a version that is different to the currently cached version and use is if we find it, but we will only search until we find it in one of the repositories.
(For dynamic versions we have the concept of the 'newest' version, so we look in all repositories and use the newest version available.)

So I think the only current solution to this issue is to not specify both the 'localRepo' and 'remoteRepo' in your set of buildscript repositories, but instead specify the repository that you wish use to provide the changing module. For example, I can get your tests to pass by removing the part of init.gradle that sets up the buildscript repositories for each project, creating a separate test-local and test-remote project with different buildscript repositories. (This is a pretty naive approach: but it demonstrates the solution clearly).

So in test-remote/build.gradle I have:
buildscript {
configurations.all

repositories

dependencies {
classpath (
[ group: 'org.foo', name: 'helloplugin', version: '1.0-m1-SNAPSHOT' ],

)
}
}

I hope this helps to explain the behaviour you are seeing, and points you in the direction of a solution. I understand that diagnosing issues with dependency resolution can be frustrating; I'm adding a bit more logging to help track down these sorts of things in the future.

I think I am hitting this as well. The solution of not including multiple repos does solve the problem...but at the expense of being able to work on multiple projects locally. I have a description of my situation here: https://discuss.gradle.org/t/multi-project-not-multi-module-developer-workflow/10513

I'm not entirely sure if dynamic versions will solve my problem, although I guess I should try. But being able to "opt in" to look at all repos for the newest changing dependency would be really helpful. Or if the DependencyResolution dsl would expose some features to be able to control the repo selection per artifact or something. In our case its a very few number of dependencies that would need this (just our corporate ones).

Any plans to revisit any of this?

Gradle has no concept of "newest" when it comes to modules with the same version. This is the case whether the version is "1.0" or "1.0-SNAPSHOT".

The fundamental problem here is our modelling of Maven Snapshots as changing modules, since Maven Snapshots do have a timestamp that can be used to determine the newest version. I think the solution would be to model each Maven Snapshot as a separately versioned component, and treat "1.0-SNAPSHOT" as a dynamic version selector. To me, this is preferable than introducing the concept that "foo:bar:X" from repo A can be 'newer' than "foo:bar:X" from repo B.

We've already made some progress down this path by allowing a dependency on a particular snapshot version. But there's more work to do to allow dynamic version selectors to work with these versions.

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.