Separating typechecking and type error reporting in two passes?

[MarLinn]

> But you are right that when the programmer sits there and waits for a
> result, that’s when snappyness is important.

I had a random idea based on this observation:
(With a certain flag set) the compiler could follow the existing 
strategy until it has hit the first n errors, possibly with n=1. Then it 
could switch off the context overhead and all subsequent errors could be 
deferred or not fleshed out. Or, alternatively, the proposed new 
strategy is used, but the second pass only looks at the first n errors.
Benefit: Correct code is on the fast path, but error reporting doesn't 
add too much of an overhead. My experience when using the compiler to 
have a conversation about errors was that I was correcting one or two 
errors at a time, then re-compiling. I discarded all the extra 
information about the other errors anyway, at least most of the time. I 
don't know if that is a usual pattern, but if it is we might as well 
exploit it.

This idea could already benefit from a separation, but we can go further.
What if, in interactive sessions, you would only get the result of the 
first pass at first. No details, but only a list of error positions. In 
some cases, that is all you need to find a dumb typo. It also doesn't 
clutter the screen with loads of fluff while still giving you a basic 
idea of how much is wrong. Now what if you could then instruct the 
system to do the second pass at places you choose, interactively? In 
other words the conversation would be even more conversational.
Of course the benefits are debatable and this is not something that's 
going to be happening soon anyway. But for me the idea alone is an 
argument for the proposed new separation, because it would give us the 
flexibility to think of features like this.

Cheers,
MarLinn