Seems like the problem is the solver can't infer the keyPath type by context form the arg conv constraint where

  (tuple_expr type='(with: $T4)' location=... range=... names=with
    (keypath_expr type='$T4' 

and

Resolved overloads:
  selected overload set choice doFancyThing: $T0 == (PartialKeyPath<Person>) -> ()

  ($T4 bindings={(subtypes of) PartialKeyPath<Person>})
  Initial bindings: $T4 := PartialKeyPath<Person>
  (attempting type variable $T4 := PartialKeyPath<Person>
    (failed constraint $T4 key path from $T1 -> $T3 [[locator@0x11d0b2a70 [KeyPath ...]]];)
  )

So, it seems like it is actually failing to find the type KeyPath<Person, Int> for .age because it is failing to find binding of $T1:=Person and $T3 := Int from the context of arg conv.

The exact point where it is failing is here

Can't figure out a solution for this yet, but just sharing some findings here that maybe can be helpful when someone else wants to take a look 🙂

cc @xedin

@swift-ci create

For future reference as @xedin described here
A way to fix this is to use an approach similar to the way closures are type-checked in resolveClosure.
The approach will be to delay the constraint generation(now done in CSGen on visitiKeyPathExpr) until the key path type variable has a contextual type available attempting the binding.
A resolveKeyPath method would perform constraint generation and resolve the key path type together with all key path components as well as resolving the capability of the key path type (read-only, writable ... ). This makes the key path constraint not need anymore, as Pavel mentioned "The reason why key path constraint exists is related to the fact that we need to wait until all of the components are resolved to figure out a capability of the key path (read-only, writable, reference writable)" and now since resolveKeyPath will have context information we would know the capability expected, this only will need to validate that resolved vs expected at this point.
In the end, the resolveKeyPath will perform constraint generation and then resolve the keypath type in a similar way it is being done in ConstraintSystem::simplifyKeyPathConstraint.

This is just a short gist, that could be useful in the future 🙂

Looks like this is a duplicate of previously reported SR-5667.