What problem are you facing?

Currently Crossplane managed resources reference a ProviderConfig by name alone. The key consumer of config is the provider code, where the type (i.e. GVK) of the ProviderConfig is fixed. Other API consumers do not have enough information to resolve an arbitrary managed resources' spec.providerConfigRef to a particular config; for example a web console could not (easily) resolve a providerConfigRef.

In theory a non-provider consumer that knew how Crossplane worked could potentially discover the active ProviderRevision for a particular managed resource (via its CRD) and then figure out which provider configs that revision installed, but doing so is complex and potentially unreliable.

How could Crossplane help solve your problem?

Crossplane could allow managed resources to include an apiVersion and kind under spec.providerConfigRef. Perhaps these fields could be optional (for backward compatibility) but defaulted by the managed resource's CRD schema?