Good catch. The present wording does seem to contain a loophole.

The proposed normative text has a bug: the origin reference need not be a resource object (think primary data from a relationship URL).

The simple change you made to the trailing note was a really good one. It now explains the whole thing so well that if the normative part can't achieve the same level of clarity, I would just promote the note to normative and build on that.

Suggestion:

Compound documents require "full linkage", meaning that every included resource MUST be referenced from the primary data either directly or via intermediate included resources.

You are right, I didn't take into consideration the case of fetching relationships directly and including its data in included (though I'm not sure I can think of a useful use-case – maybe polymorphic has-many?).

I'm not satisfied with my current proposed wording because it feels quite redundant (this is because I chose to take the transitive closure of neighbors of primary resource identifiers, and because we somehow need to identify resource objects and resource identifier objects).

How about the following:

Compound documents require "full linkage", meaning that every included
resource MUST be identified by at least one accessible
[resource identifier object] in the same document.
A [resource object] or [resource identifier object] is accessible if it is either primary data,
or it represents resource linkage contained within an accessible resource object.

Edit: concerning your suggestion, I find it great, as it conveys the intuition of what's meant to someone familiar with the spec, but I'm afraid it may be too vague for newcomers (though I'm aware being too formal won't help much either).

Formally, what we are trying to say is:

A JSON API document represents an underlying directed multigraph where resources are vertices and relationships represent arcs. Formally, for every pair of resources A, B, there is an arc from A to B labelled R if B is represented by a resource identifier object within a relationship R in A.
In this context, full linkage expresses that all resources in included must belong to the transitive closure of data.

Any wording suggestion on this one?

I'd love to see this clarified too, I know that "full linkage" has been a point of discussion multiple times while working on https://www.drupal.org/project/jsonapi.

This clarification seems to be highly needed. I think the proposed change points into the correct direction. But as pointed out by @bintoro it does not work if the primary data is resource identifier objects. I tried to improve the proposal to also consider that case.

Compound documents require "full linkage", meaning that every included
resource MUST be identified by at least one [resource identifier object]
in the same document. These resource identifier object can be primary
data or represent resource linkage contained within an accessible resource.
A resource is accessible if it is included in the same document as primary
data or if it is identified by a resource identifier object in primary data
or represents resource linkage contained within an accessible resource.

@beauby Are you still motivated to push this forward? If not, I can fully understand after more than four years. I could take over in that case and provide a new pull request with my proposal based on your original one.

Hey @jelhan, feel free to take over and I'll close this PR once yours is up!