Regarding when I think the error should be generated, we definitely want the warning to be happening at compile time, but the "compile step" is actually a series of substeps.

The point where the string parser is processing string escapes is *not* the best place to complain about unrecognised ones, as it doesn't have the ability to report the appropriate context for where the offending string exists in the code base (hence this issue report, and the misattribution problem in the generated warning).

Instead, you probably want to look at delaying generation of the error until the point where AST Bytes and Str nodes are being generated for inclusion in the AST, as at that point the code generator has access to full file, line, and column information regarding the location of the problematic escape.

However, I also expect you'll run into a problem where you'll need to be able to embed *something* in the processed string that lets the latter stage of the pipeline detect that there was an unknown escape rather than a properly escaped usage of "\\" (which is presumably why the "immediate warning" approach was attempted first - it doesn't need that ability to communicate with the latter stage of the pipeline).