So your view is basically the same as ours.
Personally I think that a lot of clients could be better developed if they were to have a multi-level development. Namely, an oper source IRC integration where-as new commands/features/communications with the various IRC's would be coded and then from there, programs, such as mIRC, attach onto it to add additional features and making use of the "gateway" in how it displays the received data, etc. That way, if a client wishes to add a new feature, they submit the request to the "gateway" coders who send back a code (equiv to the [K] or [O] controls) where it would be an indication that it's a named feature/function (but by a reference number, perhaps), similar to ANSI codes. And the client programs would automatically be backwards compatible in that there could be a design that would allow the client to know how much of the data to ignore if it's not compatible.
Of course, it is probably more complex than that, I'm sure. But hey, wouldn't it be nice if there were codes (1 byte each): [esc][len-of-feature(0-Z)][feature#/type][data][ack]
Mind you, this would be only for client designed features, whereas [i][feature][code x4] would always be fixed so if the feature isn't supported in that version, it skips 5 additional characters, but the [i]'s would be new implementations by those who develop the gateway, thus new color schemes, etc, could be added to [i], where with a limited number of features that could be added, it would be reviewed more and therefore incorporate a higher rate of acceptance and compatibility. the [esc] method would be more loosely controlled, where the "feature name" may include a 3 digit code that backreferences the client that came up with the function, and then that client could always make a new function at anytime and know that other clients will simply ignore their function if they don't support it.
Ok I'm done dreaming in a semi-perfect world now.
