If you have case x := <-c1, y := <-c2, what happens?

Both variables would have to be used in the case block:

select {
case x := <-c1, y := <-c2:
    if x != false {
        // x non-zero value received
        fmt.Println(x)
        break
    }
    // y non-zero value received
    fmt.Println(y)
}

Comma ok is another case too:

select {
case x, ok := <-c1, y, ok := <-c2:
    // doesn't compile because of repeated ok var?

select {
case x, okX := <-c1, y, okY := <-c2:

Maybe since ok is always a bool it can have the same name:

select {
// still has a lot of commas
case var1, ok := <-c1, var2, ok := <-c2, var3, ok := <-c3:
    if ok == false {
        return
    }
    if var1 != 0 {
        fmt.Println(var1)
        break
    }
    if var2 != nil {
        fmt.Println(var2)
        break
    }
    fmt.Println(var3)
case <-c4, <-c5, <-c6:
case <-done:
    return
}

There's the problem of the zero-value being sent on the chan meaning the block can't figure out which var to use.

Your example use case could be written without duplication as:

select {
case <-rdy:
	return // the client redirects to a GET /competitive15
case <-cancel:
case <-w.(http.CloseNotifier).CloseNotify():
}
competitive15Matcher.Cancel(name)
http.NotFound(w, r) // the client ignores the POST response
return

That makes sense. I don't have a good example use case.

@mvdan despite the Go 2 tag do you think this could be a Go 1 feature? It doesn't seem like a breaking change.

There will be no more significant changes to the language before Go 2.0, so I would say very unlikely.

Our use case is similar to @pciet's example.

We have a event or tick case, both trigger the same behaviour.

We ended up moving that into a function. Felt bad to allocate resources on every function call.

I'll try @neild's solution and report if we land into some other problem.

A hypothetical case which wouldn't work this way:

eventAchan and ticker trigger one behaviour.

eventBchan, a closed channel and timeout trigger another behaviour.

fallthrough for switch is something I wasn't aware of. Adding this keyword to select could have the same effect. Here's an old golang-nuts thread about that: https://groups.google.com/forum/#!topic/golang-nuts/j0RobXhmGac

When used with sends on a channel, there is no way to tell which send succeeded in a case. When used with receives that happen to receive the zero value, there is no way to tell which receive succeeded in a case (particularly important since receives from a closed channel get the zero value). The same functionality can also be easily obtained with our current select by factoring out the case bodies.