So this means that semicannonical-json is not just about the encoding of some values but also about the order of keys in some cases.

My implementation does not yet handle messages. But when it does, I was planning for message verification to just validate the signature on the message in its received encoding with whitespace expanded (and verify sequence number + previous id). If/when I implement signing/publishing of user-specified message content, I would probably then implement a function to detect and reject non-semicannonical-json. If I am feeling generous I could make it semicannonicalize JSON during publish. It is advantagous for implementations to agree on which messages are invalid: for example, @cft was able to recover their forked feed because no peers considered the messages on the losing fork valid ( %TPs53tQ...). But it is mostly on the publishers/signers to get it right I think.