We should not have parser tests that are sensitive to the line feeds of the file.
Such tests should generate the strings with `n or `r`n as desired, and if it must be read from a file (which parser tests normally don't need) - then generate the file.

This test is only for validating that the unicode escaped character isn't processed. The newlines are not important for this test unless I'm misunderstanding this test case.

IIRC it is not line feeds of the file but the fact that PowerShell here strings use `n. This test is checking Unicode esc sequences inside a here string. OTOH, we don't have to test the entire string. The point of this test was to ensure we ignore this esc seq in a single quoted here string. This test could use a regex match to look for the esc seq.

IIRC, here strings contain whatever newline the file had - it does no translation.

But the point here is - the test shouldn't be sensitive to that, e.g. if git checkouts out the file with `r`n, test shouldn't fail.

OK, I trust your memory over mine. :-) At the console, here strings use `n. But in a file, yeah, I guess it makes sense that here string uses whatever the file uses for eol.

I'll change it to a regex to handle both cases