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).
I suppose this is possible, but it would introduce backward compatibility issues. How wide-spread those issues would be remains to be seen, it would be up to Khaled to figure out if it's worth the effort or not. I personally don't mind a palette system, and, in fact, I think it's better than hardcoding colours, especially
because one of the benefits of a palette is that it's tied to user settings, not the script itself. In other words, if a user wants to apply a different theme to their local colours, mIRC could theoretically reapply the new colour scheme to an existing window by redrawing it with the updated palette-- which would not be possible if colours were hardcoded by scripts. For that reason, I disagree with this on "best practice" rationale, not for technical reasons. We would be moving in the wrong direction if mIRC encouraged users to hardcode colour values in /echo and the like. Think about what would happen if a script hardcoded some shade of blue because the exact variant wasn't in the palette, rather than defining a special index for it. Then, if a user wanted to change their background to a similar shade of blue, things would get messy really fast. Hardcoding things always reduces customizability and resiliency to change. We want to avoid that as much as possible, and indexes are the best way to do it.
That said, I don't think we disagree about the need for a standard colour system for
remote messages. This is exactly why I suggested we reserve only the indexes ABOVE 15 for local use. Users would no longer be able to redefine 0-15 (or whatever the remote usage palette size is), which would solve the "standardized colour scheme" problem, but would still allow scripts to have an abstraction for colour schemes that are not hardcoded to specific colours, which is important for scripts to coexist with user settings (and other scripts), as mentioned above.
Finally, the copy paste idea might work, but again, because I disagree with the benefit of rgb colour codes, I don't really see the value. Also, adding in another key combination for copying doesn't really sound very user friendly, especially given that your suggestion CHANGES behaviour that users have relied on for 10+ years. If anything, Ctrl+Shift+Copy should be the local copy, which would preserve backward compatibility and not be surprising to users who upgrade. This is important since the users who use colours are more often the less technically inclined, and if you changed the behaviour and started throwing invalid colour codes into their copied text, we would start seeing messy invalid codes creep into public messages. Presumably, mIRC could auto-convert ^K#NNNNNN codes when sending outgoing messages too, but now we're adding extra layers of complexity into the program simply to solve the unnecessary complexity we just added.
