Motivation

When a client joins a server that has the chat-preview feature enabled, any message they type is sent to the server for decoration so that the client can sign a decorated/server-mutated message instead of the plain text message they typed.
This system is a fundamental core feature to allow custom server software to stylize/change player message without breaking chat signatures. 

Issue

Clients that send their chat message too fast after typing the message into the chat box, send a chat message that has not been previewed by the server, as either the preview systems minimum request interval of 100 milliseconds prevented sending the final preview request or the round-trip from the server simply wasn't finished yet.

This means that fast typers (at least in my play-testing) will repeatedly end up submitting chat messages to a server without singing the preview which makes consistent modification on the server-side of things incredibly hard.

Considerations

Technically it is the players responsibility to await the last preview for the final chat message before submitting it, however this will be less and less actively in the mind of players for servers they a) trust and b) only do minimal modifications to the message, e.g. colouring.
An example would be a server that simply colours the chat grey. As players trust the server more and more, fast typers will consistently be submitting chat packets without a signed preview. The server then either has to send their plain message in white or still decorate the chat in grey and hence send a modified message to other clients, breaking the chat signature.
Neither of these outcomes are particularly wanted to keep a consistent chat without breaking chat signatures.

Potential Solutions

This is a rather complicated issue, as one has to think of the worst-case actors on the server-side, that might be modifying the entire message in those last few preview requests.
One solution that pops to mind would be simply awaiting the last server preview before allowing the client to send the chat message.

Another solution would be to simply only sign the original message. This would avoid the issue of a round trip for the preview, however obviously means that a client would see technically unsigned content and trusts the server to not create guideline-breaking messages from a fine original message.
However for this the social interaction screen could simply show the original text. If said message still breaks guidelines it can be properly reported as it is signed. If it isn't, the server was responsible for the change. How servers that intentionally mutate fine messages to guideline-breaking ones should be dealt with on a platform level remains a question with this approach, however the client server relationship already is build on trust in the server in the first place.