Thanks for the correction. I overstated what w3c/vc-di-eddsa#81 establishes. It confirms that securing the Note first, inserting it, and then securing the Create produces a valid result, but it does not define how a verifier should recover the input for each proof from the resulting compound document. I do not read the issue as explicitly limiting the valid case to merging documents after verification either, but I agree that it does not settle the verification scope.
There is a related wrinkle in VCDI: it distinguishes an unsecured data document from an input document, and says that an input document may contain a proof added by a previous process. The eddsa-jcs-2022 verification algorithm also removes securedDocument.proof, rather than explicitly removing every descendant proof. I had read that as removing the proof on the current JSON map only.
That reading still depends on first deciding which map constitutes securedDocument, though. VCDI does not say how to select that boundary inside a compound document. I agree that this is the ambiguity raised by w3c/vc-data-integrity#350, and that #81 alone is not enough to resolve it.
I also take your point about JSON-LD context inheritance. My proposed @context requirement was meant as part of a narrower JCS profile: extract each nested JSON map from the original representation, treat it as an independent secured document, and verify it as such. Giving that map its own complete @context would make the extracted representation self-contained for eddsa-jcs-2022. It would not provide general separation between JSON-LD contexts in the compound document. More importantly, the extraction rule itself would need to be defined by FEP-8b32 rather than inferred from VCDI.
I am less certain that previousProof resolves this particular case, since VCDI defines it for proof chains on a secured document and it does not by itself assign nested proofs to subdocuments. Still, I agree that Fedify should not treat signing over the embedded proof as the established interpretation while that scope remains undefined.
Fedify currently preserves descendant proofs in the outer JCS input, so that remains useful implementation experience to bring to the discussion, but it is only one possible profile. I will adjust the framing of fedify-dev/fedify#938 accordingly.