Even in evolving environments, it's important to have terminology that describes what is acceptable and what is not in clear terms.
Writing precise language is hard, but ambiguity of language is worse, since it can lead to potentially unsafe interpretation.
The Frankenstein Veto makes it possible for state Governors to alter the meaning 'near runtime' - certainly post-review - and accidentally or intentionally create loopholes which enable damaging outcomes.
But laws are already not written ambiguously. They may be written with technical jargon which may be too specific or euphemistic, but that's not quite the same thing. What you would be advocating for at that point might a common language for law that avoids euphemism and keeps the reading level at a certain level of complexity, but doing so also limits the richness of language that we can use to describe legal agreements in the first place.
Furthermore any software system that could handle the Frankensetin Veto would have to be extremely competent in natural language and somehow do model checking on all the combinations of cases that natural language can cover. Not going to happen in polynomial time buddy. Not for all sorts of law anyway.
The problem that the Frankenstein Veto case demonstrates doesn't necessarily have to be handled in software either. It's a problem with the workflow of law, not the systems implementation.
I'm asking for simple language, accessible to a broad audience, which allows rules to be written so that most people applying them to a set of example situations would arrive at the same results.
Beyond that, what I'm suggesting is that it could be helpful to gradually make it easier for the public to view, comment on, and search proposed and historic legislative changes.
Collaboration, tracking down bugs and coaching/mentoring in open source software is greatly aided by tools like GitHub; it's worth having concerns about whether such a service itself should be proprietary, but I do think the value it creates is worth looking at.
If something similar could be created for legal texts, I think it's possible that there could be similar benefits. There may be risks, too.
My suggestion isn't that we should devise a software system to implement the rules of the Frankenstein Veto; instead my theory is that the time-to-detect and time-to-recover from a process problem like the Frankenstein Veto would both be shorter in the presence of an open, collaborative, transparent legislative repository.
Writing precise language is hard, but ambiguity of language is worse, since it can lead to potentially unsafe interpretation.
The Frankenstein Veto makes it possible for state Governors to alter the meaning 'near runtime' - certainly post-review - and accidentally or intentionally create loopholes which enable damaging outcomes.