This is a nice proposal, but it's fairly short-sighted and hacked together on the premise that /echo is the only input to a window, and that no data ever comes out of that window. It doesn't answer many of the real issues you'd have with properly handling those coloured lines consistently throughout the execution of the client. For instance:
How would mIRC render these control codes when Ctrl+Copied? How would they get logged? How would something like /loadbuf know to interpret the syntax used among non-RGB codes? What would /msg # $line(#otherchan,N) do with those codes? More importantly, how would you be able to mix the 2 syntaxes in a single line? This would be extremely important for theming, since you would basically be unable to use RGB colour codes in an ON TEXT event (where incoming data might contain palette based colour codes) otherwise. You can recall similar theming problems in 6.x when scripts printed codepage characters in theme output on Unicode channels. The idea that just because it's local you can control whether you're using one syntax or another exclusively per-line doesn't actually work that way in practice.
Adding a special switch in a single command that changes the way mIRC parses an extremely common control code syntax won't work very well when you consider how the control codes need to interact with the rest of the client.
The only real way to support RGB style colours would be to add a completely new control code for that purpose; but then things get really weird and confusing for new users, especially given the ever-mounting problem that mIRC hasn't even rendered control code glyphs properly for the last 5+ years. The inability to differentiate control codes is likely to be a source of confusion and bugs, and frankly, given the rendering problems, I think it would be wiser if we found a strategy to move away from control codes, not add more.
