There are two obstacles in getting what you want to work. The second is the lack of support in /loadbuf for setting the line color based on the color in each log line (this could also be added as part of the -z switch to /filter). That would be a very valid feature suggestion.
For that, though, another obstacle needs to be fixed first, and I believe that this can in fact be considered a bug: namely, that the line color storage in the log file is ambiguous. As the helpfile states, the line color is only stored if it differs from the original color. This means that:
and:
are stored exactly the same way in the log file, namely as "<ctrl+k>04hi", even though they are different with respect to subsequent ctrl+o's or single ctrl+k's as your example shows.
As a result, there is currently
no way to reliably decide for a line in a log file, whether this log line includes a line color or not. Even when it is known that "Line colors" was turned on in the options at the time of logging.
This could be fixed by altering mIRC's logging mechanism, to
always include the line color prefix, i.e. even if the line color is actually the default color,
if the first character on the line is a ctrl+k. That would remove the ambiguity during log parsing.
For now, you're basically out of luck. There just isn't enough information in the logfile to do this right, so there are no workarounds either. For your specific case you could make a workaround (involving /filter -k and seeing if a line starts with two color codes), but it would be slow and only work with your logs with the colored timestamps..
