1. In release A, manifest A is part of cap A, while manifest B is part of cap B.
2. In release B, manifests A and B are both part of cap B.
3. User installs release A with cap A enabled and cap B disabled.
4. CVO reconciles manifest A.
5. User updates to release B.
6. While considering whether to accept the retarget, CVO notices that it had been reconciling manifest A, but that per the requested caps it will no longer be reconciling that manifest. CVO also notices that manifest A will belong to cap B. CVO says "ok, retarget accepted, and I'm injecting all of cap B into status.capabilities because manifest A taints them in".
7. CVO begins updating to release B, reconciling all cap A and cap B manifests, so manifest A keeps being reconciled, and manifest B is pulled in for the first time.

I think there's some value in reporting "you didn't ask for cap B, but it was tainted in by previously-reconciled manifests" to explain step 6 (and that overlaps with OTA-572). But we could also say "hey, you aren't asking us to reconcile cap B, but we're doing it anyway" in step 7, without explaining the "...because it was tainted in" history.