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