My re-read of the linked discussions is that a missing component was an exploration of concrete examples substantiating the claim that it would be “quite a useful feature.” Not examples of demonstrating how it could work (the rules around what’s proposed), but rather examples of real-world use cases that would be improved by the presence of the feature.
Keep in mind that with macros on the horizon, a feature that forwards to another type’s implementation at runtime would (or at least, could) be a subtly different creature from a synthesized conformance, and one salient question would be under what circumstances that behavior would be desirable and independently valuable when macros are available.
Consider specifically that specifying that implementations of one protocol’s requirements would be forwarded from one type to another would mean, if Alice extends Bob’s type to provide a custom implementation of a requirement of Charlie’s protocol which has a default implementation, Doris’s type which conforms to Charlie’s protocol by forwarding to Bob’s type would behave differently at runtime if Alice’s library is imported by the end user—without any party being able to reason about it. Further, if Charlie adds a new requirement to the protocol, which is an ABI-compatible change if a default implementation is provided, but both Bob and Doris have already implemented that functionality before it was a protocol requirement to do so, Doris’s type would (depending on the runtime version of Charlie’s library) dispatch to Bob’s implementation of the requirement rather than Doris’s own.