In general, the parameters to the pattern are the (ordered) concatenation of the parameters of the channels following [When] which is simple to specify but, as you rightly observed, easy to get wrong. So I agree with you that the syntax is a little clumsy and could be sugared to or even replaced by something more concise and less error prone. I had actually considered precisely the explicitly typed syntax you suggest - in fact, we already had this in Comega for purely asynchronous patterns. The even better implicitly typed variant make perfect sense, and is close to my ML heart, but is less in keeping with VB.
Apart from implementation expediency, the main reason I opted for the explicit variant is that it is similar to the [Handles] syntax, makes it easy to override patterns in subclasses and to support recursion in the body of the handler as well as debugging and testing of patterns. Perhaps we should support the fully explicit syntax as well as sugar for the more concise, even implicitly-typed form that generates a private, non-recursive method. Heck, we could also just jettison the [Handles] analogy completely...
Another thing one might consider adding is the ability to declare that a channel handles some events and (for symmetry) that an event is raised by some pattern.
The main motivation for departing from the Polyphonic C# syntax was that decoupling channel and pattern declarations makes it easier to support inheritance and the addition of new patterns in subclasses.
We’re definitely open to suggestions and very grateful for your feedback.