The reason we went for a more type-centric approach here is that we wanted to express the fact that a derived conformance is available only when all of the struct/enum parts (stored properties and/or associated values nested within) conform to the same protocol. I believe it is not possible to express this statically with a less typed approach like KeyPathIterable. You could provide a "blanket" conformance that statically works for any type, but it could only fail at runtime if parts of the type are non-conforming (which is too late). Any form of optimization at compile-time will have to respect this failure to preserve the semantics.