In this case, we don't have good data representations for code which produces or consumes structured data, where the structure of that data changes over time. We have some pieces figured out for certain domains, such as database schemas, but we do not have a "theory-of-everything" for enforcing types/structure across all domains of our systems. The domain addressed by GraphQL, HTTP APIs, is another instance of this same problem.
There are experimental systems like Unison that keep old versions of your code alive as data, which are fascinating solutions to the underlying problem.
Did you read the article? The issue isn’t code vs. data, it’s code vs. system state. The system can be in states not model-able by code, e.g. versions 1 and 2 of a piece of software running concurrently. Other examples I can think of are things like nodes going down, database consistency, etc.
Technically, not "not model-able" but "not modeled". As in, the effort was not done, and is easy to omit. And doing it in the general case is a lot of work, hence the expand-contract and only-two-versions designs.
