Marking for consideration for 2.13.2. /cc @lrytz

That's pretty clever, to simplify the import exclusion. So now you get one shot at exclusion; it can be triggered by an arbitrary lookup, but the idiom must be a preceding package level import? If the source has two packagings, does order matter? I'd have to try it. Actually, an import in a sibling packaging would not be an enclosing context. Maybe you choose not to support that; it might trigger the error; in addition, I now think this is a terrible feature anyway and should receive minimal support.

Also, I verified that the determinism test fails, but the scala signature diff is not meaningful to me. The test for ordering of the implicit class defs is more obvious.

The repl knows if it has to insert the import somewhere, but maybe the template breaks the test t11897. t1931 is also repl, a SessionTest!

neg/predef-masking.scala should just work. Oh, is it because the import already triggers lookup? So the second import no longer excludes -Yimports:hello.world.minidef.

import hello.{world => hw}
import hw.minidef.{Magic => Answer}

I'll take a look; my speculation was wrong, so I'll have to refresh how namers works...

A solution for the non-determinism for root import exclusion (scala/bug#11867) eludes me, so I've reduced this PR to solving the issue of stabilizing the order synthetic modules in Scopes (scala/bug#12066).