Report parse errors with source locations and maybe suggested error repairs
Hammer can tell you whether your input parses or not and take actions based on it when it does. A compiler front end might well tell you the exact line and column where the semicolon should have been. Hammer should know how act more like that instead of the proverbial compiler that only ever says "you lied when you told me this was a program". Ideally, it should be reasonable to use Hammer to build a compiler front end.
A possible theoretical approach to this: the input language strictly defined is embedded in two nested sets, the loose input language consisting of correctable statements that are 'near' strict inputs, and the larger set of strings over the input alphabet that are not even recognizable as near the strict language. We can conceive of each string in the strict language as embedded in a basin of attraction in the loose language, and the error-repair relation as a homomorphism from the loose language to the strict one which picks out a canonical interpretation. This becomes close to Postel's law, and lets us reframe the usual langsec critique of it as "many implementations have not clearly thought through what their canonicalizing homomorphism or loose language are, in ways that lead to surprising and dangerous results".
This is likely to be a complex feature requiring theoretical consideration, API design and then support in individual backends. Thus, it is placed at the end of the current roadmap, Hammer 3.0 at the earliest.