In addition to the aforementioned problem the following inputs are also different between 10.6.1 and 10.6.2

Thanks for the feedback!
I created the PR for fixing the behavior!
#7012

Thanks for the quick turnaround.

One question: per the PR I see that some cases (e.g. "no sources should return undefined") are not really what I expected, that behavior is different to how it was in 10.6.1 (always returning an empty object) and I expected a change like that to be considered a breaking change (i.e. released in a major release)

Here I assuming graphql-tools follow semantic versioning or a similar versioning

Thanks

We follow semantic versioning, right.

The behavior was broken and not intended as you can see in the tests. There is no change in the API but the result is corrected in the PR. So it is a bug fix not a major breaking change in my opinion.
mergeDeep takes an array of values to be merged. So if there is no value in the passed array, it should be undefined not an empty object.
If an array with undefined values passed, nullish values should be ignored like you expected in the original issue, and the result should be undefined.
I am not sure if relying on a broken result is a good idea.
Let me know if I am missing something here.

Well, that behavior has been how this tool has been working for a long time if I'm not mistaken, and as this particular case was not documented afaik, we assumed that to be the expected behavior (always return an object) and relied on that for our tool as we don't have any checks for the result after mergeDeep

I agree that relying on unintended behavior is not ideal, and we are not massively affected by this as we can always add some extra checks on our end before updating, but wanted to warn about the potential breaking of other tools by this fix