I did use the search on multiple phrases, none of which contained those items, so please don't assume that I did not. It looks like Sat didn't find your initial post either.
I likely found nothing because I searched for terms including "parsing," (since that's really what this post was regarding) and not "evaluation," they key word in your two references. I turned up a myriad of /timer items, but far too many to go through in a day.
Anyway, thank you for the references. Considering that it has been over a year since the post was active, it's probably about time that it was refreshed anyway, as there is still no easy workaround. It isn't a priority, no, but as you noted yourself, it would be handy.
To be specific, I'm discussing more along the lines of Sat's proposition for -n (avoid timer execution parsing) as opposed to yours (avoid timer setting evaluation [too?]), since it seems the hardcoding that is implied on yours can just as easily be done manually using $chr and $!, etc. (if I'm incorrect on this, let me know). Avoiding parsing execution, however, requires more than simple escape methods. Yes, $! can work for Sat's first example, but when you start involving arbitrary phrases from incoming IRC lines (especially brackets), this gets difficult/annoying to escape repeatedly. Hrung sums up my feelings best below:
This would allow things like using $1- on a timer in an on text event without having to worry about what happens if someone says a $($decode(),2) line. Sounds like a great idea to me. I also think such a switch should be added to /scid and /scon so that various scripts for doing things such as relaying text from one chan/network to another is risk free without writing needlessly complex code. It's not dissimilar to the n switch to $read, so maybe making it -n is suitable.
In response to KingTomato: I appreciate the help, but the suggestion here (and on the other posts) revolves around avoiding excessive escaping. Both of those require a $regsubex to avoid replacing "attached" versions. The braces one also requires the external reference, which, if done within a script, I believe would evaluate already and we'd be back to square one.
I'm sure we could figure out a way to escape everything, but that's a lot of excessive work to simply forward a text string. Thanks for offering those workarounds, though.