Right now, the spec forbids multiple resource objects with same (type, id) from appearing together in a compound document. I think the theory is that allowing duplication could result in the same resource being sent with two different sets of fields:

Note: This approach ensures that a single canonical resource object is returned with each response, even when the same resource is referenced multiple times.

Also, deduping saves data over the wire.

However, neither of those rationale make much sense to me: if the spec can require that a resource not appear twice, it could just as easily require that, if it appears more than once, it must always appear with identical content; and, with gzipping, the extra data from duplication is probably not much of a problem.

Moreover, my sense is that this forced de-duping comes with a real cost for server implementations, which have to track all the resources in the response document as they build it, or do an O(n) traversal through the response before sending it. As an implementer, this has always seemed like more trouble than it's worth, and I've simply skipped doing that check.

So, what are we actually getting from this restriction? Is it really worth keeping?

Btw, re the spec requiring instead that "if a resource object appears more than once, it must always appear with identical content", that's only one option (and would be very easy for servers that do all their queries inside a transaction to guarantee, without extra overhead). Another option would simply be to tell the client to take the representation that occurs latest in the document.