This means that a protocol that just adds completely generic syntax without specific semantics is ill-defined. This is my thesis too, by the way, and the reason why I resist towards using (and advising for) protocols just for the sake of adding explicit conformance to something that could be there already, by being intrinsic to the semantics of the type.
A decision must be made here. Given the obvious utility of a chaining step with something that's not a method on the type, we should explore the options. To make for a productive exploration, we should identify the constraints. The fact that implicit members are discouraged in Swift doesn't mean that are forbidden, and .apply is the prime candidate for being an implicit member. If implicit members are forbidden, but for exceptional cases, well .apply is the exceptional case: it's something that can and should be used on everything. If implicit members are forbidden without exceptions, then .apply will never happen without a protocol conformance. But as a protocol, it would be ill defined. There's no escape, the only possible outcome is that something like .apply is not a proper Swift construct. Otherwise, some step in the argument chain must be wrong. But if this is the thesis, then we should abandon altogether the idea of chaining only with member functions.
The only possible alternative I can see relies on operators. But even if the needed functionality was there (like keypaths on all members), operators don't mix well with members calls, and member calls are a cornerstone of Swift code. Which means that Swift, on this regard, is inconsistent, so the language itself, its current state and previous dicussions about some of its specific features don't represent a frame of reference that's good enough for this particular discussion. Hence, some kind of guidance must be provided to push this forward.