Well, that is how the language works. Permitting a label on a case or default clause would be hard to define, because of code like

    switch x := v.(type) {
    case int:
        goto label
    case float32:
        break
  label:
    case int32:
        // what is the type of x here?
    }

In other words, the same reasons that prevent you from jumping into a block also prevent you from jumping to a case clause.

Since this is the way that the language is designed and intended, I'm going to close this issue.

Well, that is how the language works. Permitting a label on a case or default clause would be hard to define, because of code like

    switch x := v.(type) {
    case int:
        goto label
    case float32:
        break
  label:
    case int32:
        // what is the type of x here?
    }

In other words, the same reasons that prevent you from jumping into a block also prevent you from jumping to a case clause.

This is only a problem in a type switch.
See how switch deals with fallthrough in type switch :
https://play.golang.org/p/6VwniYemffi
error with : cannot fallthrough in type switch.

I don't see why the same thing can't be done for goto.
In your example the build would just error with something like this: cannot jump in type switch.
For all other non type switch this would just works.
What I want to do is exactly the same as a fallthrough except a fallthrough use the natural increment of rip while I want to move rip using a jump instruction. I don't see any major difference.

True, it probably could be made to work, but the cost would be another exception to the language.

If you want to propose a change to the language, see https://golang.org/s/proposal. But I would not accept this proposal to be accepted.