A request like https://musicbrainz.org/ws/2/release/8e061dc4-790e-4587-ba53-011e7852f88d?inc=release-groups+media+recordings+puids+artist-credits+labels+isrcs+artist-rels+release-rels+url-rels+recording-rels+work-rels+recording-level-rels+work-level-rels should not contain work-level relationships back to other recordings, because these recordings are either not on this release or this relationship is already returned for the related tracks.
Per a comment by @voiceinsideyou on
With analysis, ~1172 / 1223Kb (95.8%) of the XML data is work level ARs back to /other/ recordings - it's 50kB without these. Pretty sure the numbers are correct; I manually went through the XML and cut out these blocks. Nirvana is especially bad, probably due to the live bootlegs project, and likely a large number of unmerged recordings, however I'm not sure whether Picard uses these back-references, but given the impact they have - perhaps there needs to be a way to filter these work <- has performance of -> recording ARs out, but still get composer ARs and the like?
While I didn't perform a new analysis, I'm guessing this is still accurate. The response size of the same request has ballooned to 2.82 MB since that comment was made in 2011, and there are still tons and tons of these unneeded relationships in the output.