The topic has been covered, I just thought I'd give an example on how this feature could mess up scripts.

A very common practice among multiserver-enabled scripts is storing variables (or hash table items) whose names contain $cid, for example:
Code:
on *:join:#: set $+(%,justjoined,$nick,:,$cid) 1

This way you can distinguish between "qwerty" on network1 and "qwerty" on network2. $cid is used because CID numbers are unique, that is, each "connection" (the quotes are due to the fact that you can have more Status'es than actual connections) has its own number, which cannot be the same with that of another connection. Nothing else can play this role. Network names, for example, aren't unique (you can have a clone connected to the same network as your regular nick for example, so $network returns the same thing).

Now say you have 2 scripts loaded, yours and a 3rd-party flood protection script. If your script issues the proposed /scid -h and happens to use such variables, the variable %justjoinedqwerty4 (which was set on CID 4) now points to an inexistent session. The CID that was 4 is now 3, so any script that tries to evaluate the aforementioned variable on that connection will try to evaluate %justjoinedqwerty3, which of course doesn't exist. But even if you don't care about that because you don't use such variables, that 3rd-party script you're using does. And the fix is not a matter of "rewriting the script": there simply is no fix for this, because there's no way of storing connection-specific information without the uniqueness and constancy of CIDs.

On the other hand, nobody has provided any example that shows the usefulness of such a feature...

/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com