It is worth noting that mIRC differentiates between identifiers that take parameters and those that don't when choosing between built-in identifiers and custom aliases.
I know that. I bet you assume I didn't know that because I requested for $noop() to be unoverridable. I request that because I am keeping in mind the way $null() currently acts with its overridable behaviour! I'm sure you will argue that it's because there is also a $null (without parameters) and there wouldn't be a $noop without parameters, but unless it's implemented we won't know how it will be. What I'm saying is that if it gets implemented, I don't want it to be overridable. If it turns out that this wouldn't ever be an issue anyway, well great, even better.
Given the fact that mIRC is often modified with backwards-compatability for scripts in mind, it would seem to be a break with tradition to treat /noop specially. Due to that, and the points made by previous posters, I would prefer that this was left alone.
Why is backwards compatibility a factor here? /noop has only been introduced with the last version. In fact many people are still clinging on to .16 waiting for a bugfix release. Besides, it's not like mIRC hasn't ever broken scripts due to changes, remember $null's behaviour changing in an older version, which broke a lot of scripts. I'm not saying my argument is better than yours, rather that both our arguments aren't really an argument, as examples of both cases exist.
