[RFC] Non-existent request field operator

As it currently stands, the “breaking change” GraphQL best practice is largely based upon the assumption that server schemas are never older than client schemas, which is not the case for self-hosted instances of server software that are not centrally managed.

For example, GitHub client applications may desire to query the newly added `hasVulnerabilityAlertsEnabled` field on the `Repository` type to provide additional information to the user if available. However, adding this field to the query is sure to break the compatibility with servers on earlier schema versions, such as GitHub Enterprise users.

This effectively leaves the same problem as traditional REST APIs — every change can be seen as breaking. To ensure both backward and forward compatibility, the client has to resort to either separate queries or API versioning. Both of the workarounds are against the design rationale of GraphQL and quickly become unmanageable with the rolling schema iteration encouraged by GraphQL design.

There should be a way to specify that a field in the query may be non-existent, or “I hope your server have some clue about this field but do not panic if not and just give me whatever you have now“. The need is not satisfied with nullable fields or error policies because it is a validation error instead of a resolver one.

If null is to be used as the sentinel response value of non-existent field, this operator shall imply non-null.