It is not about replacing a single \E, but possibly many of them. If you have a function, which accepts a binary search string S, in where you have to replace each "\E" with something like "\E\E\Q", you face serious difficulties coding in AHK, because S might contain \0's, RegEx control sequences, AHK escape sequences, %...% look-like references, etc. The resulting function should work with any combination of these special cases, which could make it long, complicated and "ugly". It has nothing to do with "if your program is so poorly designed without fault tolerance and control": but working correctly with all possible input. A "\E" might not cause errors, but faulty results.That is only true if your program is so poorly designed without fault tolerance and control. This is often a cause of bugs and security holes which AutoHotkey's uniquely simplistic syntax aims to prevent in the first place. It's ironic how you find the need to replace a single \E so mundane and 'ugly' knowing the overheads of a machine code function.
\Q...\E does not help
I don't want to suppress alternatives, but they have to work, or at least their limitations should be documented. This is what I try to do. So far we discovered
I never expected that you would be so adamant to suppress alternatives techniques. Raw buffer searching and regex have their trade-offs and either are suited for different applications.
1. Workarounds for passing binary HayStack to RegExMatch with the proper length information
2. Similar workarounds for setting the length of a binary Needle surrounded by \Q...\E
3. One restriction for the search string (no "\E" inside)
It is not clear that there are no other restrictions, so we have to keep on looking.