The messages are sent as extra messages, duplicating timestamps and faking senders and overall it's pretty ugly.

The Quassel protocol supports this, unfortunately it looks like the quassel team doesn't care about taking it further than where it is.

Full disclosure: I am one of the developers on the aforementioned IRC server.

In a future release InspIRCd will adopt support for the server-time extension which will allow us to get rid of the timestamp duplication if a user's client supports it.

Interesting. Can you tell me what you think of Quassel as a protocol?

It's very specialized and last time I looked at it, it was based on Qt types and other ugly things. It would not be realistic as an alternative protocol for IRC itself.

Just a note that the QDataStream format is documented, and has been implemented in other languages such as Java. That doesn't mean that the Quassel protocol should replace IRC of course. :-)

Timestamps – there's a standard extension for this (see IRCv3 above). ZNC has been using it for maybe a year.

Senders – there's absolutely no reason to fake senders, since it was always valid for messages to come from people not in the channel.

It sends some channel messages after the JOIN. The new IRCv3.2 specification (being formally ratified across vendors soon!) adds a BURST type to make the protocol transactional which will allow displaying the messages in the right order with a little bit of work on the client side.