[bonch]

Well, look at one of my examples: RPL_NAMREPLY, which returns a list of nicknames in the channel, prefixed by channel privilege. One privilege is returned at a time according to the protocol, despite the fact that a user can have multiple privileges at once, such as +vo. If such a user is deopped, your tool won't know that they are +v unless you have taken the steps to gather this state previously (this also means there is a period of time after joining a channel in which you're not in sync with the channel modes the server is seeing).

There are extensions to the protocol to support returning multiple privileges in RPL_NAMREPLY, but now your tool has to support both modes of operation. Additionally, the usual medium for discovering these extensions, RPL_ISUPPORT, slightly differs between networks, and today there are now multiple ways to query a server's capabilities, so you have to support RPL_ISUPPORT, PROTOCTL, CAP, and possibly others I haven't seen, and their features overlap. Also, none of these are officially standardized.

All this adds up to needless hassle when you're trying to implement a full-featured framework or tool. These are problems that should have been officially addressed years ago so that everyone is on the same page.