If you want to add support for a new kind of register class in GCC, do you refactor everything as you make your change? No, you'll break a dozen architectures you've never heard of. Instead, you add some logic in a self-contained way, conseratively, assuming you don't fully understand the corner cases of the existing implementation. It's much easier to understand new logic as a delta of existing behavior, which may be then partially specified, than to reimagine the logic from first principles.
That's why the law is full of "But in cases under subsection C where Z applies..." You don't refactor subsection C because you may break it. Better to specify the additional behavior in a self-contained way. You can summarize the behavior of a legal code in diagrams, the same way you can diagram the high level operation of GCC's register allocator. But the diagram isn't the code, and the diagram can't be canonical.
I tried Googling it, but I think my terms are wrong. How is this typically dealt with? Does one stricly supercede the other (i.e. revocations win over acceptances), do postmarks come into play, or similar time of transmission evidence?
This is all off topic, but I never thought about this scenario before.
The problem with design, especially with the example given in the article, is that it only captures the most basic, generic information. The detail--the part that matters to specific applications of the law,i.e., the most important part--is left out. (For example, the sample design on contracts leaves out crossing responses, a very common event in where rejection or acceptance of a contract is sent after an offer has been revoked but before the revocation has been received.)
Law is complicated because it needs to be to deal with the very many edge cases that arise from the natural ambiguities inherent in language. There are limits to how simple law can be.