To clarify the implications of this approach as I understand them - Graph Node would need to introduce graphQL API versioning (currently there is only the latest), and the ability to answer queries for historical versions as well as the latest. That versioning could be indicated in the URL:
https://gateway.thegraph.com/api/[api-version]/[api-key]/subgraphs/id/[identifier]
Any feature that changed the graphQL API would require a version bump (even if it is simple addition of a field).
This pattern (for prior version compatibility) exists already in Graph Node for the mapping apiVersion. It would add complexity in Graph Node’s graphQL implementation, and may have some operational or performance implications (I have not fully investigated this). And this would not be about conforming with graphQL compatibility (which allows for simple additive changes), but protocol compatibility.
Let me know if you have a simpler implementation in mind @Brandon and @That3Percent . This does not seem too onerous, and would seem to simplify the situation by creating entirely deterministic query responses. But would be great to clarify if this is a requirement ASAP, given in-progress and planned changes to the graphQL API.