+1. I don't like the "generic protocol" syntax for multiple-input protocols for exactly this reason.
I think an argument in support of that syntax would be similar to the argument in support of method syntax. In the case of methods it is very common to have function that is very closely associated with one of the parameters. Method syntax provides convenience by recognizing that and bundling the method with the type it is closely associated with.
The analogy with protocols would exist if it was common to have a protocol with multiple inputs where the semantics of the protocol is obviously most closely associated with one of those input types. I don't believe this is actually the case. As @Joe_Groff mentioned, the most widely known use cases do not exhibit this relationship, thus making "generic protocol" syntax a bad fit for the feature. Further, I think this syntax would be confusing and / or duplicative along side a generalized existential feature that used
where syntax to constrain "input" types (currently just
Self) and associated types.
All of that said, I would really like to see support for multiple input types added eventually. Unfortunately I don't have any good ideas for syntax to offer.