If everything is nullable, then the client has to deal with enormous null checking overhead for things that may have no immediately good reason to be null, simply for error handling. Otherwise, just as in the not-null case, they will blow up when the schema changes.

Moreover, if the absence of a value for some field has semantic meaning, the UI often needs to do very different things for an error versus an meaningfully absent value. So now, the errors block has to be fed everywhere that the data block goes to determine whether something was absent or erroneous. That sounds really silly to me.

I do think you’re right though —statically-typed protocols without versioning cannot go from not-null to nullable. I just think the better answer is deprecation in favor of new queries, and have the server produce the backward-compatible result to the old spec until you’re capable of pulling the plug.