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).
