Assume your graphQL use case is working with stored graphQL operations. Once you add this special meaning of null, null is no longer infrequent in the data itse

Assume your graphQL use case is working with stored graphQL operations. Once you add this special meaning of null, null is no longer infrequent in the data itself, so using null to represent delete is a good idea on the existing data and then a bad idea once implemented (is this an attempt to delete a part of a query or is the query a delete query, or both?) A new patch must follow, etc. Homoiconic languages and channel protocols are crafted to avoid this kind of meta rat races with their own representation. null is actually the null object, so if an object is not expected the use of null is wrong, a key should exist but it's value is undefined. AFAIR even most DOM operations are correct in this distinction. undefined as a value does not mess with Object.keys or hasOwnKey.. it truly is what it claims to be and is truly distinct from a never existing value in JS. JSON is buggy, but we knew that. Trying to get metadata on the data channel instead of the opposite is buggy, but we knew that too. Better things exist to implement a proper interface today, i.e. one can use Symbol to distinguish current runtime metadata that truly can not collide with the data.