See also #19905 (the first point) and #18516. In order to completely eradicate all the usages of `UnknownTcRnMessage` from GHC, we would need to tackle the functions inside `GHC.Tc.Utils.Monad`, namely: * `mkLongErrAt` * `mkTcRnMessage` * `addLongErrAt` * `add_err_tcm` * `addErrTcm` * `addErrTc` * `failWithTc` * `failWithTcM` * ... (the list goes on) All these functions construct, directly or indirectly, an `UnknownTcRnMessage` by taking an `SDoc` as input, which is not great. This task is _potentially_ newcomer friendly, but the developer would probably require some guidance, because we would have to carefully untangle the zoo of logging functions from the `GHC.Tc.Utils.Monad` in favour of a more consistent API, or at least make sure that all these functions takes as input only `TcRnMessage`s. Doing such refactoring will inevitably trigger a cascade effect where now GHC will complain in every place where they are used. There are two strategies out of this: 1. Fix the usage sites of these functions by wrapping the (old) input `SDoc` with a `TcRnUnknownMessage`. This will just shift the "problem" elsewhere, but this is a good thing, because now it would be evident which are the remaining diagnostics which need porting, just by the virtue of a `grep TcRnUnknownMessage`. This means creating more newcomer friendly tickets to port those; 2. Go "all in" and complete the conversion of the messages while we do this refactoring, all in one glorious patch. My recommendation would be (probably) to go with `1.`. Yes, we might create more churning in the end, but it feels like the advantages would be `A.` more community/newcomers involvement and `B.` smaller MRs to review.