I think I found the root cause:
With
Treat CR and LF Separately disabled
and radio button Regular Expressions enabled.
EmEditor’s Find in Files will interpret \n as LF as soon as the search term contains a regular expression token or actual regular expression.
Without a regular expression token, EmEditor behaves as if performing a Escape Sequence type search, presumably because this will speed up Find in File’s performance.
{ and } are regular expression tokens, but most engines will treat it as a regular character until written as a complete regular expression, e.g a{3} for aaa.
Most of this is in line with EmEditor’s Help, which states:
● Find dialog box → Regex on → \n or \r\n (same meaning)
I.e. \n will match both CR+LF and LF.
● Find in Files dialog box → Regex on → \r\n, \r, or \n (depends on actual newline character)
Elaborated further in EmEditor Help → Tips
which explains that \r strictly matches CR and \n strictly matches LF, …
… what is not explained in help is that
1) the Find in Files regex search will fall back to an escape sequence search when the search term does not contain at least one regular expression token
2) escaped regular expression tokens as in \{ , are no longer identified as regular expression tokens, with Find in Files then performing an escape sequence type search.