$chr(0) definitely does not work with the way mIRC handles C strings. You can only get \0 inside of bvars, so that severely limits its use. I highly doubt you'll ever see this change. Way too many moving parts in mIRC rely on C strings right now, and changing all of them at once would result in HUGE amounts of new potential security issues. This is absolutely not worth it.
I still disagree with your proposal of using only 0-15 for legacy compat. Specifically, again, because what we need is more LOCAL indexes, not over the wire colours. At the end of the day, I don't think Guest18542 cares whether Jane158 thinks the "Royal Blue" is a smidgen too dark for her liking. Local colours are the issue, I think... and as I pointed out, there are already 20 local events that could benefit from having their own separate index, which is already more than the allocated space, and that doesn't even count any user defined colour codes. User defined colour codes being the most important part here.
You're also not going to get an "agreement" on 80 more colour codes from other IRC clients at this point in time, so that makes it harder to implement this over the wire stuff. Local changes can be made much more easily.
As for your comments about Ctrl+Shift+C, I think I might have been reading it the other way around the first time, thinking you would copy remote codes and translate them for local use. I see your point now. The problem is, many users already hit Ctrl+Shift+C because they aren't entirely sure whether the combo is Ctrl+C or Ctrl+Shift+C. Both work right now, so this change might be surprising to *those* users.
I think an IO routine would be more appropriate though, and would be needed anyway, since those codes could leak out no matter what. For example, a script could accidentally or even intentionally send ^K<localuse> codes if that data is being shared for both local and remote usage -- see my example to Riamus a couple posts back regarding storing of user input variables.
