[c3RlcGhlbnI_]

No, it isn't easy but that is what makes it the kind of thing that requires great spec work to accomplish. It would require proposing transitional steps and monitoring their adoption over a very long timeline.

However reading their site more carefully I suppose their stated goal technically is to only provide extensions to the protocol.

So the situation you describe already happens, user A has 512 bytes to send to the server, but the server has 512-prefix_length bytes to send to B. This is a flaw in the original protocol and the currently accepted solution is to truncate server-side(what to do is not stated explicitly, though it is implied that you probably shouldn't wrap messages). But fixing it is probably out of scope.

[caf]

The prefix is discoverable by client A though: it can send a self-message and thereafter knows the maximum length it can send to any given target.

[lfowles]

They will only know the prefix for the server they are connected to. On a larger network such as Freenode, client B could be connected to another server with a different prefix length.

[caf]

The prefix doesn't involve the server. The prefix that's prepended to your messages when another server passes them on to a client is ":nick!user@host " and is the same for all messages that you originate.

(On Freenode and other networks with a similar service, your hostname can be changed by services, but the client is notified of this and can update its knowledge about the prefix).

[lfowles]

D'oh, you're right! I looked at a non message command to refresh my memory.