@OlegIlyenko I will try to do detail review in the next couple of days. But from top of my head, it also should include @deprecate.

@IvanGoncharov thanks! Good point, I focused on @skip and @include and completely forgot about @deprecated. I updated the PR.

Partly alternative proposal based on #429 (comment): I think we can define the behavior of multiple @skip/@include.
We could change this:
http://facebook.github.io/graphql/June2018/#sec--include

Neither @Skip nor @include has precedence over the other. In the case that both the @Skip and @include directives are provided in on the same the field or fragment, it must be queried only if the @Skip condition is false and the @include condition is true

into this:

Neither @Skip nor @include has precedence over the other or other instance of the same directive. In the case that multiple @Skip or @include directives are provided in on the same the field or fragment, it must be queried only if all @Skip conditions are false and all @include conditions are true

This also require to change this algorithm:
http://facebook.github.io/graphql/June2018/#CollectFields()

Benefits: Currently you can model only OR for includes:

{
   field @include(if: $foo)
   field @include(if: $bar)
}

These proposal allows to do the opossite operation:

{
   field @include(if: $foo) @include(if: $bar)
}

I like this suggestion. This lifts the constraint and defines intuitive disambiguation rules.

I still struggle with the question of why such a strong line is drawn between:

1. field @skip(if: false) @skip(if: true) (disallowed by validation)
2. field @skip(if: false) @include(if: false) (allowed)

both variations are semantically identical (and raise the same ambiguity issues). In my opinion, if we keep that validation around, then it probably should be reason other than ambiguity between @skip and @include. Though it makes sense for @deprecated since there is no straightforward way to disambiguate 2 of these (except just to pick first or last, which is probably suboptimal).

Maybe I should prepare the third PR that is a combination of #472 + non-unique @skip and include + the change in the text that you have suggested. What does everybody think about it?

To follow up from the WG meeting: I think we should extract the skip/include rules from the deprecated to ensure we're leading to the right solution for each. I'm excited about the direction of clearing up ambiguity when using skip and include together

@leebyron sure thing. i think I would prefer to first finish #470 and #472 to not mix things too much. Later on I think this PR needs to be closed and I can open another one which is dedicated to skip/include interaction.