> The hazard with this approach is that the suggested syntactic correction

> might simply lead the user farther into the weeds

I don't think there's enough experience to justify this claim. Before I experienced the Berkeley compiler, I would have thought such bad outcomes were inevitable in any language. Although the compilers' suggestions often bore little or no relationship to the real correction,  I always found them informative. In particular, the utterly consistent style assured there was never an issue of ambiguity or of technical jargon.

The compiler taught me Pascal in an evening. I had scanned the Pascal Report a couple of years before but had never written a Pascal program. With no manual at hand, I looked at one program to find out what mumbo-jumbo had to come first and how to print integers, then wrote the rest by trial and error. Within a couple of hours  I had a working program good enough to pass muster in an ACM journal.

An example arose that one might think would lead "into the weeds". The parser balked before 'or' in a compound Boolean expression like  'a=b and c=d or x=y'. It couldn't suggest a right paren because no left paren had been seen. Whatever suggestion it did make (perhaps 'then') was enough to lead me to insert a remote left paren and teach me that parens are required around Boolean-valued subexpressions. (I will agree that this lesson might be less clear to a programming novice, but so might be many conventional diagnostics, e.g. "no effect".)

Doug