The problem is that whatever new colour indexes are added have to be customizable. This is one of the most important requests in each colour discussion. Users want local use colour palette that they can modify to fit their schemes. There is not nearly enough granularity in your proposed palette to back off from customizable palettes, and therein lies the rub.
IF mIRC adds colour codes, they need to be private use. In other words, they should not be meant for sending data over servers. Frankly, I think we have enough colours in 0-15 to represent "colours" on IRC-- what we need is colours 16-98 that can be reserved for local client usage. That way, mIRC would not use 0-15 for echoing local data and instead use codes 16-31 (or fewer) to represent the various event types.
For instance, $color(info) would be mapped to 17 instead of 2, $color(ctcp) would map to 19 instead of 4, etc.-- this would allow every event type to have its own colour code, rather than multiple events sharing a single colour (like join/part/kick/modes). It would also let users change the event colours without affecting colours coming from users, since the indexes are separate. And being local only, it will have no effect on the existing control code support in other clients, since nobody else will be seeing codes above ^K16.
Of course, we could meet in the middle here and reserve a smaller set of values for "local use" while still extending the "remote colours" range to ~64 or so. 32 local colours should be sufficient for a client side scheme, although it does cut it a bit close (there are 20 event types in Alt+K, which would mean about 20 separate local use colours would be reserved for these events under my proposal, leaving only 12 for custom script usage).
Alright, I understand your thinking and can say that I mostly agree. One exception however: if mIRC ever does introduce private use colors, they absolutely should not use the ^K#[#],#[#] format. That would automatically harm future efforts to expand the over-the-wire IRC color palette, which would undoubtedly seek to use any or all of ^K's presently-free values. No client should hog a public resource to itself, even partially.
That being said, as long as a private use system wasn't limited to the boundaries imposed by the ^K#[#],#[#] format, it could be a true RGB system: perhaps using a format like ^K#FFFFFF (where # is literally the # symbol).
Ideally, both ideas could be implemented simultaneously. I still think the 16-98 palette idea I proposed above has merit in two ways: because (IMHO) 16 colors
aren't enough, and mainly, because a non-customizable palette would at long last bring color consistency to IRC: knowledge that the colors you were sending out were being seen
as you sent them.
(A thought: because the palette design I propose is still very granular -- multiple luminosities of all primary, secondary, and tertiary colors, it would also be possible to create a CTRL-SHIFT-copy function if both systems were simultaneously implemented. CTRL-SHIFT-copy would scoop up all ^K codes verbatim (as CTRL-copy does now). CTRL-copy however would be changed to assume you intend to paste what you've copied back into the channel/query window, and would replace every local ^K#FFFFFF code encountered with the ^K#[#],#[#] color having the nearest-matching hue. This would solve the problem of "how would CTRL-copy deal with local colors?".)
