I think I understand the broad design as you describe it, but understanding the details is difficult because the number of changes in the WIP patch is so staggering. It would be great if the final version could be broken up wherever possible, and have documentation & explanatory comments added.
In particular it might be helpful to split into at least two patches: the first introduces the ability to resugar (i.e. the Resugarer : TreeTransform<Resugarer> class and the Sema::resugar overloads which use it, I think), and a second patch would make use of this ability to produce the desired diagnostics (and other independent uses of resugaring, if any, would go in their own patches). This would help clarify the purpose of the many secondary changes throughout the codebase.
Also, can you comment on how ASTMatchers or other AST tools might make use of resugaring? Or is this strictly for improving diagnostics?
A broader issue that might be considered is whether a flag should be introduced which disables all type sugar, everywhere, for faster compiling whenever accurate diagnostic info is not needed (because diagnostics are not expected/will not be acted on by the user). Implementing might be as simple as tweaking the QualType ASTContext::get*Type(...) implems to return the inputted canonical type, unwrapped, when this flag is enabled. This would alleviate the developer’s burden of deciding whether further info should be piled into the AST via sugar, at the cost of performance – a decision which is probably better left to the user. Adding such a flag might make it justifiable to resugar eagerly in this case.