@Tim Makarios (on Manyverse)

You are right, that scenario actually breaks things. So the remaining question is: "Can you still break it if we always use the certificates that can be created when the message itself is created"? If the answer to that is "yes", then we can probably scrap the whole thing. And if the answer is "no", then I'll need an actual proof for that. Proving that such a scheme works is something I'd do in any case before rolling it out.

I'm also thinking right now about using additional backlinks further back into the list rather then using the additional hashes (the blue nodes) for bridging disparate trees. It seems kinda weird that there are different mechanisms (combined hashes vs single-message backlinks) for establishing creation order.

What's more, if the bogus hash of m5 doesn't contribute to h6, why can't I rebundle m6 with a new certificate, this time based on the real hash of m5? Then even careful verifiers that verify everything won't detect a problem.

m6 creates a backlink to m5, or in your scenario, a bogus backlink. A "careful verifier" can just traverse all backlinks, so there's no way of fooling those.