To remind, the original context was transpiling another language (with semantics that allows irreducible CFGs) to Zig, not just this one specific pattern. Yes, of course, for pretty much all practical code, there is going to be a better equivalent. But the transpiler doesn't get the benefit of only working with practical code - it has to deal with whatever the source language spec says is legal. So you need to come up with a generic solution to the entire class of problems presented. Which does exist - e.g. Relooper (https://mozakai.blogspot.com/2012/05/reloop-all-blocks.html) - but the point is that it is very much a non-trivial transformation, to the point where it might actually be easier to transpile to C or something else that has full-fledged goto that you can just use directly.
Relooper goes the other direction though. We don't need to produce high-level control flow. For a transpilation-to-Zig use case the algorithm can be extremely dumb. Naively translate every loop (or any other control flow containing nontrivial internal gotos) into a labeled switch, then partition the bodies at each goto statement, making a new label for each such location.
The only thing you're really losing is that the goto is bounded by an enclosing function, but that's also the case in C, C++ and other languages written by non-masochists. From a developer ergonomics perspective you _might_ want a proper goto instead of having to rely on a clunky general-purpose transformation as described above (though I've yet to see that use case), but from a transpilation perspective it's extremely easy to just treat labeled switch as a bunch of gotos, replace other control flow with gotos, and lower an entire function into something that compiles optimally.
