What problem are you facing?

Crossplane and its providers use a lot of references between custom resources. In some cases these are "typed" references, including group, version, and kind (GVK) information:

spec:
  fooRef:
    apiVersion: example.org/v1
    kind: foo
    name: cool-example

In other cases they are "untyped", for example:

spec:
  fooRef:
    name: cool-example

Historically we've used untyped references in cases where the types could be "filled in" by the controller. Cross-resource-references are one example of this - a "Subnet" managed resource controller always knows that a vpcIdRef field will be to a VPC so it doesn't need the type information at the API level (it's baked in at the code level). We've used typed references when the code didn't know what type would be referenced - typically when a reference could be to more than one type of resource. An example of this latter case is an XR referencing its composed resources.

The challenge with "untyped" references is that systems that consume Crossplane APIs don't have access to the information baked in at the code level. A web console for example probably doesn't actually know what a "Subnet" managed resource actually is and thus has no way of knowing what type its "vpcIdRef" field references. crossplane/crossplane#2255 is another example of this - it blocks systems like xgql being able resolve untyped references per upbound/xgql#37.

How could Crossplane help solve your problem?

I believe we should standardize on typed references everywhere.