your right about how it could be different, but there not going to change it, and I would be one of the first to start critizing if they did, changing the nature of a command could cause problems for any number of existing scripts, someone may already be using $ifmatch as a method of returning data from a called routine, even if there are more conventonal means to do it.
Now if a $ifmatchlocal was added that would be nice.

On the examples i showed, i wasnt meaning what he would like to happen i was meaning what does happen.

I have used this in its simplest forms like searching for a matching line of text in a file if its not $null do something with it, and rather than searching for it again, just using $ifmatch to retrieve it, and more complexely once or twice in a set of conditional checks where you might want to force a method as such
if ($1 == /me) || ($1 == /say) || ((%forcesay == $true) && (/say == /say)) { Sendtochannel $ifmatch $2- }

Or if you want to check a bunch of things and use the first valid one such as
if ($1 == Lisa) || ($1 == Jane) || (($1 == miss) && ($2 == Debbie)) { //say Welcome $ifmatch }

* ok that example is pretty lame, but shows how $ifmatch well pick out the name using $1 or $2

I like the command just as is, but i agree with you that it would be nice to have a reliable local $ifmatch

In fact I stuffed someone else script up once by having my own "alias echo" it checked some things then displayed text most of the time as normal, his script did a if then echoed something then used $ifmatch, by then i had caused $ifmatch contents to change, big oops.
Fixed it by storing $ifmatch contents then doing a.... if (%holdifmatch == %holdifmatch) { }
i cant amagine someone looking at my script later thinking , whats this crazy doing comparing if something is the same as itself then doing nothing.

PS: i love brackets, lots and lots of brackets ;-)))))))))))))