@Avarei I've been looking to solve the same thing. Is maintaining this in a fork what you went for in the end or did you choose a different path?

@j2L4e sadly I had to prioritize other tasks above managing gardener from crossplane. I hope to get back to it early next year but for the moment I don't have the capacity.

Back then I was not really sure how actively I should push for this change, since it uses the providerConfig fields in quite an unusual/different way.
The kubeconfig contains the credentials to the seed-cluster, instead of the actual target cluster and the identity section contains a secretRef which just contains a reference to the actual cluster to use.

I also thought of an alternative approach that might be a good substitute.
The idea is to create a Disposable Request in provider-http.
it could create the kubeconfig secret and refresh it automatically.
sadly it also needs a PR to work, since provider-http needs mTLS support to work with the kubernetes API.
If this sounds interesting, take a look at crossplane-contrib/provider-http#21

Frankly, having provider-kubernetes depend on gardener/gardener for this rather specific use-case, doesn't feel quite right.
Using provider-http to reconcile ProviderConfigs for provider-kubernetes much better aligns with how you would handle kubeconfigs coming from other cluster-providers.
Thanks for linking the mtls-issue, I'll look into that!

Edit: Got it working using provider-http, token auth instead of certs and insecureSkipTLSVerify. Which is good enough for a POC. Thanks for the hint, @Avarei.