7 and 07 are the same, they both represent the same color. One is simply padded. mIRC is using the simplified syntax of the current colour that begins the copied snippet because it does not have the full context for the initial color code. This seems intentional to me.
You should really have tested this with better inputs, you would realize that simplifying to 7 does NOT lead to potential bugs-- if the text starts with a number, mIRC intelligently uses 07 instead:
//echo -a $chr(3) $+ 07 $+ 7654321
Doesn't seem like a bug, just yet another one of your odd expectations. mIRC should have the right to simplify copied control codes wherever it can. The Ctrl+O is certainly intentional. Why does mIRC have to return exactly what was in the buffer when you are only copying a snippet of the line? mIRC is rebuilding part of the line here, specifically the part with the color code (because it was not copied, it was reconstructed).
The difference between copying the text and the whole line is that your copying caret begins after the color code in the buffer. It would seem impossible to tell mIRC that you want to copy an invisible character in the buffer, so mIRC assumes you are pointing to the location AFTER the color code. This is a fair assumption. Especially since this would be the same as if you copied from the '5' or the '4' in the above example. In other words, copying from the "7" is equivalent to copying from the "6", "5", "4", etc.. The behaviour is consistent with copying text after a code was inserted. mIRC only knows that the current color is $chr(3) $+ 7, it doesn't know (or need to know) the exact syntax used to begin that color sequence. Yes, the two copy behaviours might differ, but that doesn't mean one is a bug, it just means there are two separate cases depending on context. Each one works consistently and produces correct valid results, what's the problem this time? Is there an actual scenario where this doesn't copy the right COLOR that you wanted? If it's copying the right color but in a different form, it's still the right color, and mIRC is still correct.
If you're asking for mIRC to optimize the copying routines so that copying from a character that immediately follows a color code would copy the preceding color code byte sequence as well (rather than reconstructing it as it would for any character following it), that would be a feature suggestion, not a bug report. As it stands, mIRC seems to work as I've described above, which seems intentional, correct, and consistent.
