introduce semantics for "allowable changes via a schema version bump" that pair w/ existing semantics regarding "changes that require a schema version bump"

[jrevels]

...with an intention that the only allowed changes are those that can be supported by robust forward/backward compatibility pathways that are implementable by CRUD-encapsulated storage systems that "support" Legolas semantics

this would obviously be a "breaking change" to Legolas' documented semantics / intended usage, but unlocks a lot of the practical utility of Legolas as a framework

if one DOES want to make a disallowed change to an existing schema, the go-to response would then be "this can't be a new version of the same schema; it needs to be a new schema entirely, give it a different identifier"

EDIT: also, canonicalize a notion of "version 0" that might not uphold these constraints moving from "v0" to "v1" (in SemVer-esque fashion, a 0.x series implies breakage is allowed). a great idea introduced internally at Beacon by @dmfay

EDIT 2: an aspect of this highlighted internally at Beacon is that it would, for the most part, eliminate Legolas' allowance of "non-version-bump-inducing changes" in practice, as pursuing this issue would entail tightening the core Legolas version principle "Do not introduce a change to an existing schema version that might cause existing compliant data to become non-compliant" to "Do not introduce a change to an existing schema version that might enable the creations of records after the change that violate the previous constraints"

EDIT 3: another aspect: schema ownership (e.g. owner in the sense of <owner>.<name>@<version>) and "user-extensibility". different regimes of changes may or may not be allowed depending on whether the owner declares support for "user extensions"; user-extensibility can be granted as a new version of an existing non-extensible schema