Ugh, this is annoying. I will write a post today about using a binary format with an implicit schema for the non-freeform (i.e. non content) fields of messages. This can be done in the most simple and efficient way if the order of these fields is fixed. Messages with the new hash prefix required for hsdt can introduce that, but I hoped the same format could apply to the rpcs that send semi-canonical json as well. But more on that later today. I woke up to a page of notes scribbled at 3 A.M, there are a lot of posts incoming for you guys today...

I propose at the very least, rejecting messages that do not have the signature last

Yes, please. This is super important for the opt-out-of-legacy-verification-details mechanism I sketched at the end of this post (and which I plan to flesh out today).

Every current message has a hash field, but it's not checked. that means the current implementation would still accept messages missing the hash field.
We should make this required

Or drop it. What value does the field have if it is not required? Is it used anywhere at all? Or does it simply duplicate information already in the multihash suffix of the signature?

But, prehaps we can take advantage of this opportunity to add a version field?

Version of what (honest question, not rhetorical)? Don't we have the hash suffixes to indicate message formats already?

Thankfully, this means the signature is not mutable, but the hash is.

Can you clarify this? As I understood you post, the signature field always uses the correct value, but cypherlinks can contain garbage. Is this correct?