What does backwards compatibility mean for optionals?

[hansbogert]

The docs show the following paragraphs

The instance relation for structs has an analogy in software engineering: backwards compatibility. For a newer version of an API to be backwards compatible with the previous version it must subsume it. In other words, the old version must be an instance of the new one. Or yet another way to say it: a new version may not forbid what was allowed in the older version.

With optional fields it gets a bit more subtle, but basically, an instance may change an optional field to required, but not remove it. The backwards compatibility metaphor applies here as well.

Especially that last paragraph does not rhyme with me, at least as an end-user interested in concrete values/output. Perhaps thinking in concrete output is the crux of my confusion and the documentation merely is restricting itself to cases of backwards compatibility in cue schemas which can be non-concrete.

Anyway, my confusion at least comes from the following situation where we have a definition with an optional:

#a: {
  a?:int
}

b: #a & {
  a: 7
}

c: #a

Evalling, shows:

b: {
    a: 7
}
c: {}

We should now be able to change the optional to a required and remain backwards compatible:

#a: {
  a:int
}
// ... same

Evalling, shows:

# cue eval -c backwards.cue
c.a: incomplete value int:
    ./backwards.cue:2:5

Admittedly, not requiring concrete values, does not result in an error:

#a: {
    a: int
}
b: {
    a: 7
}
c: {
    a: int
}

My question then becomes, can cue help with backwards compatibility guarantees for use-cases where we think in concrete values? For example, you could argue that backwards compatibility for a use-case as above could be achieved by changing from optional to required, but with a default concrete value. Does the theoretical lattice-model help with reasoning about backwards compatibility for concrete values?