I suggest making an identifier to "unevaluate" a string, so you can correctly pass it in remotes to a /scid or /timer. For example, if you have in remotes: timer 1 1 join $1 and $1 contains something like #$someid() it will execute the $someid identifier instead of joining #$someid(). This thing exists in a lot of scripts, and there should be an easy way to "unevaluate" the string before passing it to a place where it will be evaluated twice.
alias -l real {
;; $chr(40) = (
;; $chr(41) = )
;; $chr(44) = ,
if (!$lock(decode)) return $+($,decode,$chr(40),$encode($1-,m),$chr(44),m,$chr(41))
;;; $ decode ( data , m )
else {
return $1-
}
}
This is the alias I've made long time ago for personal use, then I was doing timer 1 1 join $real($1) and everything was working fine. However, there are lots of scripters that don't think that "timer 1 1 join $1" might be a security issue, or they know but they're too lazy to fix. My workaround is not great either, since it won't work properly if $decode is disabled, but some other workarounds can be written to work fine with $decode too.
There should be something like $eval(somestring,-N) which will "unevaluate" N times so I'll do "timer 1 1 join $eval($1,-1)" and have no problems.
If you just want a simple script to join a channel 10 seconds after a user tells you to, I doubt you are going to write such an identifier yourself. Still, people won't know that they have to use $eval(,-1) before passing a variable to a timer or scid function, so I also suggest adding some more information into the help file in the timers section and Multi-Server section telling them to use this $eval(,-N) function before passing variables since they are evaluated two times.
Summary of my suggestion:
1. Adding $eval(something,-N) as an opposite of $eval(something,N)
2. Updating documentation and telling the users the risks about the double-evaluating of variables.