People assume that IRC as a protocol is not fantastically outdated and it's architecture is inherently distributed and fault tolerant. Even if those things are not really true (at least not at the levels that other moder modern systems would be considered at), people hold onto the belief.
Imagine user A negotiates a length fo 1024 bytes with the server, user B negotiates a length of 2048 bytes.
User B sends a message via the server to user A.
What happens?
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.
(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).
And how would it be split?
Or should there be a mechanism for reassembling message frames?
Imagine you have a 513 byte tag in a message.
We are working on it but when you have hundreds of different implementations which are all broken in their own way its not as easy as just adding a way to negotiate the length. Extending the length to add an extra 512 octets for message tags was a temporary fix.
>Now if they had started with fixing the actual protocol they wouldn't have had to deal with that.
We HAVE started with working on fixing the protocol. Almost all of the specifications in IRCv3.1 and most of the specifications in IRCv3.2 fix core protocol issues.
Adding tags forced them to increase message length because of how IRC messages are hilariously limited to 512 bytes in all directions. In the existing protocol you already have to guess how long your messages are allowed to be because the server tacks on a prefix to your message before relaying it, which can require it to truncate characters to fit the modified message into the length limit. Having some amount of tags tacked on as well would have made it impossible to guess how much room you had.
Now if they had started with fixing the actual protocol they wouldn't have had to deal with that. Honestly this feels more like a standard "let's add cool stuff" push than intelligent stewardship of the protocol. I guess that is kind of cool too though.