As nikomatsakis is apparently busy making the compiler faster 
, I’m going to step in here and flesh out the motivation for the breaking change:
Please let us all remember that the goal of stability is to keep breakage minimal. Breakage in this context is defined as some build (or worse, program) failing that would otherwise have passed. Breakage as a risk has basically two dimensions: 1. Cardinality, as in how many builds break, and 2. Severity as in how much work will have to be expended to find and solve the problem? (That’s why a failing program is worse: It is usually harder to find the problem)
@diwic Please don’t let your fear of breakage cloud your judgement. There probably will be some breakage sooner or later. Even a language like Java (which leans quite heavy on the conservative site) has to live with it. Asking the team to stop changing the language for loss aversion is just bad policy.
Thus, our question becomes: Is the breakage that would result from keeping the current setup plus improved compiler error smaller than the breakage resulting from changing the language; also including a suitable compiler error and documentation (perhaps referring to the old setup and how it was changed).
Based on the analysis from @brson and @DanielKeep , we can deduce that the cardinality of breakage for this change is probably low. I think the severity for those few who rely on the old rule can be minimized by suitable compiler diagnostics: if I understand it correctly, relying on the old rule would result in a compiler error under the new rule. Thus the cost of finding the error is negligible. If the error message is as useful as I’ve come to expect from rustc, I believe the cost of fixing it will be reasonably low.
On the other hand, there have been recent reports of people tripping over the current setup, which is, as nikomatsakis points out, unintuitive. Thus there already is some breakage, that will only increase in cardinality, as more and more people discover the feature. Even if we would improve the compiler diagnostics, this setup would at best reduce the severity of the resulting breakage, not the cardinality.
Thus, changing the rule and adding sane diagnostics (plus a googleable blog post / documentation of the change) will reduce breakage even more than just adding better diagnostics. Therefore, my vote goes to implementing the change. 