It's not exactly a standard, it's not exactly obvious.
1. There is no HTML markup to represent colours. HTML markups represents content, not layout. The closest you can get is the deprecated <font color="#aaa"></font> syntax.
2. Any HTML/BBcode syntax is likely to be way more obtrusive than control codes are. "<color=red>hello</color>" is already 17 characters longer, and that's only for a single colour. Multiply that by 8 and you're talking about ~140 characters of markup in your editbox that have nothing to do with the message. mIRC's current system could represent the same codes with just 16 characters.
3. Using HTML syntax to declare control codes means you can't use those same HTML codes in a message unless mIRC creates some magical way to escape HTML syntax, which would lead to all around ugliness. Its probable that someone would want to send a message including the literal "<color>" tag. Control codes on the other hand are out of the printable range, so can reasonably expect that they are not part of any IRC message.
I think the real solution here is, as suggested, just to extend mIRC's 16 colour palette to 0-98 (99 is reserved) and allow each one to be customized. This would support the current syntax and would need no changes. It's unlikely people would complain about 99 colours being too limiting. mIRC could also reserve 100+ for local colour palettes which scripts could take advantage of.
In this case, rather than having to find a syntax to support in /echo, you could keep the same syntax and have scripters setup their palettes in advance. mIRC could extend the /color command to register colours to any index at 16+. This would be advantageous to scripters, since it gives you built-in customizability. mIRC could provide its own interface for users to manage their palettes and scripts wouldn't have to. Also, scripts wouldn't be able to screw up by hardcoding colours in their scripts, since everything would be indexed.
The new /color command could be in the form:
/color [-r] <index> <rgb> [optional name]
You could then use it as per the following example:
/color 100 $rgb(255, 200, 215) NewUser
/echo 100 -a NEWUSERNAME
Of course, scripts would not call /color each time they /echo, they would do this in their initialization (ON LOAD), so it would be the same as setting their global state.
Also, $color(NewUser) would == 100 in this case, so you could use that too:
/echo $color(newuser) -a NEWUSERNAME
mIRC could then provide an extension to the Alt+K dialog to customize all of these registered colours. This would mean any theming script could offload its colour customization settings to mIRC's Alt+K dialogs, making the interface a lot simpler and streamlined for the users.
The only problem I could think of would be multiple scripts registering the same indexes. One thing mIRC could do is opt to remove the index altogether and just use the name via $color(NAME) to refer to any custom colours... but IMO that would make the simple case more difficult. I'm not sure colour clash would be that big a deal. The compromise would be that mIRC could make the index optional so that it would be auto-assigned if missing, that way scripters (who cared) could make use of /echo $color(symbolic_name) instead of numeric indexes and not worry about index collision.
