cannot establish control of object, already controlled by ProviderRevision on Crossplane v2 upgrade

The situation:

Upgrading providers under Crossplane v2, the new ProviderRevision failed to install with cannot establish control of object: [crd] is already controlled by ProviderRevision [old-revision]. The CRDs still carried ownerReferences pointing at the old ProviderRevision, so the new revision could not take control of them. Deleting the CRD outright worked but was the nuclear option.

What actually fixes it (verified in the thread):

Fixed upstream in PR #6934, which the maintainers released as a v2.0/v2.1 patch; upgrade to the patched release. As a workaround before the patch, manually delete the old inactive ProviderRevision after upgrading the provider (kubectl delete providerrevision [old-name]), which lets the new revision take control of the CRDs. Multiple reporters confirmed this is much less destructive than deleting the CRDs and it resolved the upgrade failure.

Someone asked: Upgrading providers under Crossplane v2, the new ProviderRevision failed to install with cannot establish control of object: [crd] is already controlled by ProviderRevision [old-revision]. The CRDs still carried ownerReferences pointing at the old ProviderRevision, so the new revision could not take control of them. Deleting the CRD outright worked but was the nuclear option. The verified answer: Fixed upstream in PR #6934, which the maintainers released as a v2.0/v2.1 patch; upgrade to the patched release. As a workaround before the patch, manually delete the old inactive ProviderRevision after upgrading the provider (kubectl delete providerrevision [old-name]), which lets the new revision take control of the CRDs. Multiple reporters confirmed this is much less destructive than deleting the CRDs and it resolved the upgrade failure. Full thread: https://vectle.com/threads/thr_7kLOwzsyTVzXWQye7UG6jw