I haven’t had time to really digest this lastest direction, but here’s some stream-of-consciousness reaction.
For clarity, I want to re-state what I think is the combined proposal you have in mind:
- Absolute paths always begin with a crate name, where
crateis the way to refer to the current crate. - In the new epoch,
usestatements must use absolute paths. - Outside of
usestatements, you can freely use in-scope names or absolute paths; in-scope names shadow external crate names.
Thus, any use path can be freely transported into an expression with the same meaning (modulo shadowing).
I don’t agree to the “minimal churn” point for the same reasons as previously stated: almost every file will have to change, regardless. I think we should set that particular point aside.
If we take the “flag day” approach (as in my bullets above), then the experience when copying from StackOverflow will come down to our error messages when you fail to write a leading crate on an import; I suspect we can make those quite good. Notably, however, that’s the equivalent of implementing fallback.
We could consider retaining leading :: as a disambiguator for referring to extern crates that are shadowed; like today it would mean “this is an absolute path”. But normally it would no longer be needed.
I imagine some folks will be nervous about the possibility of shadowing, but the chances of compilation succeeding on an accidental shadowing are vanishingly small. The fact that Java follows this model does suggest that it’s probably a pretty safe bet.
re: implementation, we essentially already have this with the prelude today, which is treated as a fallback for resolution. We could quite literally inject into the prelude, as @matklad originally suggested.
Overall this seems like a reasonable addition to the design space. I suspect it would lead to a somewhat decreased use of use, in favor of e.g. just writing futures::Future in-line.
The loss of 1path here doesn’t seem like a deal-breaker to me. As I argued in the initial RFC on this topic (with leading crate), the fact that all use statements will use absolute paths, and in particular references within the crate start with crate, will be a very easy reminder when moving up a relative path that you need to add a leading self:: (or crate::).
IOW, I think I want to step back on the full-on commitment to bi-directional 1path, and consider the more global tradeoffs including ergonomics. That’s not to say that I prefer this proposal yet, but just that I’m open to it 
When I have more time, I’ll try to write a head-to-head comparison of what, I think, are the two “leading” proposals in each “camp”.