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.

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.

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.

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).

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

User A gets two messages like SMS that can be joined? Or is that too naive?

What if the message is a configuration message that can’t be split?

And how would it be split?

Or should there be a mechanism for reassembling message frames?

That's what I mean. Like SMS it's a syntax that would allow for smart clients to re-assemble the message but is visible in plain text for backwards compatibility

Why is the config message bigger than the standard minimum?

Because a message can contain message tags, and other config stuff.

Imagine you have a 513 byte tag in a message.

or 511, because C told A that this was a funny number and faster for some reason.

The standard would specify a minimum and then you'd be able to go up from that in multiples of it up to a different maximum. If that doesn't jive with the client the client can go screw itself.

At least negotiating it would make the minimum width en route more knowable. Right now you don't really know. The system can't even perceive this aspect of itself well.