Currently, with the delegating client, suppose we have the following scenario:

ctrl.NewControllerManagedBy(mgr).
  For(&corev1.ReplicaSet{}).
  Owns(&corev1.Pod{}).
  Complete(&rsController{Client: mgr.GetClient()})

// later, in the reconciler
  var sec corev1.Secret
  if err := c.Get(ctx, mySecretName, &sec); err != nil {
    return ctrl.Result{}, ctrl.IgnoreNotFound(err)
  }

Because we're using the delegating client, the client will automatically set up a cache for secrets, even though we're not explicitly watching them. This makes cache establishment pretty transparent, which can be nice, but is also fairly magic, and can be a big foot-gun. Consider:

ctrl.NewControllerManagedBy(mgr).
  For(&corev1.ReplicaSet{}).
  Owns(&corev1.Pod{}).
  Complete(&rsController{Client: mgr.GetClient()})

// later, in the reconciler
  var pod corev2.Pod
  if err := c.Get(ctx, req.NamespacedName, &pod); err != nil {
    return ctrl.Result{}, ctrl.IgnoreNotFound(err)
  }

Notice here, we're triggering based off of core/v1.Pod, but we fetch core/v2.Pod. This causes the client to set up a whole new cache (duplicating storage) that's potentially in a different state than the one we're reconciling off of. This can cause confusing behavior, like getting a reconcile for an object we haven't seen yet, a delete for an object that still seems to be in our cache, etc.

I think, before 1.0.0, we might want to reconsider this behavior, and make it optional-opt-in, with a separate mechanism in case you want to set up non-reconcile-triggering caches for whatever reason.

/kind feature
/kind bug