* Comments on the proposal

Hi, thanks for this extensive and in-depth work.

I will try to keep my comments concise (which might make them sound agressive, apologies if that's the case, it's definitely not the intent)

This PR touches one of the most challengeable founding philosophical choices of GraphQL: having 2 different type systems for input and output.

I understand that the sender -> receiver relation is an unbalanced one: the sender has obligations, the receiver has options.

However:
 - ALL GraphQL users use programming languages (Javascript, Java, C#, Python...) which make no difference between input and output types
 - I actually don't know any other protocol that does that (is there one?)
 - having 2 different type systems for input and output solves (does it?) an implementer problem, not a user problem

The lack of polymorphism on input is only a side-effect of the aformentioned original choice.
In an unreal world, rather than tweak GraphQL to fix that, it would be time for GraphQL2, unifying input and output types (amongst other improvements).

That's very unlikely to happen, but saying so helps forming an opinion on the various proposals:
 - adding yet another polymorphic construct only available on input 'smells' like increasing confusion 
 - it would increase the gap between input and output type systems, rather than reduce it

From there, I think proposal #5 @OneOf is the most useful one:
 - it acts as a constraint on existing type constructs rather than yet another type construct
 - it expresses the required behavior much better than proposal #7

* Comments on the proposal

Hi, thanks for this extensive and in-depth work.

I will try to keep my comments concise (which might make them sound agressive, apologies if that's the case, it's definitely not the intent)

This PR touches one of the most challengeable founding philosophical choices of GraphQL: having 2 different type systems for input and output.

I understand that the sender -> receiver relation is an unbalanced one: the sender has obligations, the receiver has options.

However:
 - ALL GraphQL users use programming languages (Javascript, Java, C#, Python...) which make no difference between input and output types
 - I actually don't know any other protocol that does that (is there one?)
 - having 2 different type systems for input and output solves (does it?) an implementer problem, not a user problem

The lack of polymorphism on input is only a side-effect of the aformentioned original choice.
In an unreal world, rather than tweak GraphQL to fix that, it would be time for GraphQL2, unifying input and output types (amongst other improvements).

That's very unlikely to happen, but saying so helps forming an opinion on the various proposals:
 - adding yet another polymorphic construct only available on input 'smells' like increasing confusion 
 - it would increase the gap between input and output type systems, rather than reduce it

From there, I think proposal #5 @OneOf is the most useful one:
 - it acts as a constraint on existing type constructs rather than yet another type construct
 - it expresses the required behavior much better than proposal #7

* Update InputUnion.md

* clean up merge dirt