Unstable compiler output depending on order of package.scala and client code that uses type aliased defined therein

[retronym]

Here's a variant in userland, where the package object does not participate in root imports.

  @Test def testPackageObjectUserLand(): Unit = {
    def code = List[SourceFile](
      source("package.scala", "package userland; object `package` { type Throwy = java.lang.Throwable }"),
      source("th.scala", "package userland; class th[T <: Throwy](cause: T = null)")
    )
    test(code :: Nil, permuter = _.reverse :: Nil)
  }

When th.scala appears before package.scala, naming the PackageDef in th.scala with:

    def enterPackage(tree: PackageDef) {
      val sym = createPackageSymbol(tree.pos, tree.pid)
      tree.symbol = sym
      newNamer(context.make(tree, sym.moduleClass, sym.info.decls)) enterSyms tree.stats
    }

... forces the info of the the package class symbol, including entering the members of the package.class. Again, we end up with two symbols representing the same entity which results in a different (albeit semantically equivalent) pickle. I'm pretty sure there is also a correctness bug here in that references to members of package.class that no longer in package.scala might not result in "no such symbol" errors.

Originally posted by @retronym in #12086 (comment)

[SethTisue]

@retronym I've milestoned it Backlog, but you could re-milestone if you like

[retronym]

Possibly fixed by this idea: scala/scala#9664