For the record, when digging into this I discovered the environment was being initialized for every module as if it had these imports

import Prim
import Prim as Prim

regardless of what the user was doing. Now it allows these imports to be rewritten if they are specifically included. It's not great that it needs importing with and without qualification, but I have an idea about how to fix that as part of the fix for #1647 too. It's currenty necessary to have it qualified as generated names (like when {} is desugared into Prim.Record) still go through the name desugaring process, so the usual rules about the available scope apply. I'm thinking some generated names should/can be handled differently. This is a knock-on from the change a while back that only allows explicitly imported things to be resolved, even if fully qualified.

Can you explain a little more why we need both imports, maybe by giving an example? I'm not seeing it.

type Test = {}

is desugared into

type Test = Prim.Record ()

With no import Prim as Prim it complains that Prim.Record is unknown.

I assume this is to do with the order in which the various desugaring steps happen? Couldn't we just desugar it to Record (unqualified) then?

I assume this is to do with the order in which the various desugaring steps happen?

Well, kinda. Desugaring isn't the right term I guess, since it comes directly out of the parser as Prim.Record, so the other representation is lost before we get to the AST even.

Couldn't we just desugar it to Record (unqualified) then?

We could, but that only works if someone hasn't done import Prim hiding (Record), and/or defined type Blah = Record. I suppose it's true someone could still do import Prim (String) as Prim and still break it, but... whatever - like I said, I'll have another fix for that aspect soon 😛. This change is only an improvement on what we have, it's not adding something that didn't used to occur, it's just now it's done in one place rather than two.