Nobody is saying that these shouldn't be reported. I think qwerty is simply explaining why this might not be a good idea to touch, but more importantly, why it's not entirely a bug, but a limitation of the engine. No matter what Khaled chooses as a new sequence of characters in the changed eval code (if it gets touched), there will be a reserved sequence that is unusable-- this will inevitably cause problems for some users.
You might think $`~(1) will never be used by anybody, but eventually someone just might come right back to this very forum with a new "bug" saying that weird things happen when they use $`~(1) in their replacement.
Therefore the reserved sequence might as well be something that is common enough to at least be predictable. The user who ends up running into a bug with $`~(N) is going to be orders of magnitude more confused about what the problem is than a user trying to use $N, because at least there is precedent for $N being reserved in such identifiers. Burying these gotchas deeper in the engine doesn't solve the problem, it just hides it from *you*, and that inevitably makes things less predictable... and unpredictable languages are just *bad*.
I think Khaled should simply document that $N shouldn't be used within $regsubex, that at least will solve the confusion surrounding this engine limitation.
