Cool! Just seeing this RFC now from the link in [RFC] Restructure Clang's diagnostic objects to allow for nested diagnostics.
This proposal reminds me a lot of the Test Anything Protocol aka TAP. When test harnesses had ad-hoc per-project reporting, it was difficult to present the test results from running multiple different projects’ test harnesses at once. TAP broke this into a two part problem; have a specified interface between the test results and how those test results are displayed.
Another time this came up was when I was working on an app to play music; a contributed didn’t like my (bad) UI and suggested we split the front-end from the back-end.
So that’s two clear examples to me where adding an interface allowed for decoupling information production from how it’s presented.
I can see that being used here. Instead of Diag and DiagnosticsEngine eagerly emitting strings to llvm::errs() (stderr); if we had a specified interchange format (like SARIF) then DiagnosticsEngine could emit that, then we could have different consumers of displaying that data. One such consumer could be a “terminal consumer” (basically, what we have today when running clang from the command line). Another could be a clangd server or whatever else imaginable.
I also like @efriedma-quic 's suggestion about passing error codes; then the viewer/presenter can decode that however or in whatever language they prefer.