I'm hoping I can find some time to pick this up again soon, but I think what I have here works as a proof of concept, so I'm interested to hear what people think of this approach. Alternatives I can think of:

• Don't desugar names at all, and instead keep something the Imports around during type checking. Disadvantages: much more invasive
• Add a new field to the Qualified data type to keep the original qualified names of things around as they were written in the source file. Disadvantages of this: it doesn't account for things that aren't written in the source file. For example:

module Main where

import Data.List as L

x = L.fromFoldable [1,2,3]

It would be nice to be able to produce a suggested type signature that says x :: L.List here, so that the user can simply insert that into the source file and have things Just Work; this approach allows us to easily do that.

I'm also tempted to get rid of the new field in TypeRenderOptions and instead have the type renderer always print all qualifications that are present, and let the caller strip qualifications if that's what they want. In general I think keeping qualifications is the correct default.

I've not had a chance to look at the meat of this yet, but I'm excited! I did take a stab at this years ago too but my branch got behind master and the diff was too much to deal with.

Keeping Imports around to handle names is how the compiler worked in the very early days, and it was a nightmare IMO. I'm interested to look into what you've done here, because my approach to this was just to include more data in Qualified, as per your second suggestion.

I don't know how much the changes to golden test outputs reflect a work-in-progress state of the implementation versus what you're trying to achieve, but a number of them are, if not mistakes, steps backward in my opinion. Broadly:

• An error message located in module Main (resp. any other module) mentioning a type defined in Main shouldn't requalify that type with Main. (e.g. https://github.com/purescript/purescript/pull/4337/files#diff-47e1a0e39055f49fad89ffd0a5dddb92a320a6453e23a3660f335ca4971fe8ba)
• Unless the type in question is shadowed or Prim is explicitly imported with another name, Prim types shouldn't be requalified (e.g. https://github.com/purescript/purescript/pull/4337/files#diff-87c6bb64fbdf17350a93ed5f6abf83817c67eb15daa95e0cf569102a388c492d)
• We shouldn't break custom type errors, obviously (e.g. https://github.com/purescript/purescript/pull/4337/files#diff-70fa5597d1aab516a244868874c9448772555faf57b99399e42cd21596ee0d84)
• Re-exports need to be accounted for such that, e.g., Data.Unit.Unit isn't fully qualified when import Prelude is present

Provided none of those objections pose difficulties for the approach, the requalification pass makes a lot of sense to me.

Completely agree - this is far from what I’d consider ready.

This has been superceded by #4409