"Intuitive" is not enough: the order of evaluation of conditions matters (the fact they are not mutually exclusive and create complex conditions that are split and spread across large spans of code, can be challenging for refactoring. For this reason if the switch branches are complex (and cannot just call a single function or perform a single assignment but contain structured statements or many assignments and calls, it's safer for refatoring to first evaluate the conditions and use goto's with clear labels, then develop each label.
There are caveats however due to local variable scopes when they are declared or initialized in specific subbranches. There's no general "good" solution that matches all needs.
For finite state automatas, it's generally better to use many gotos and group the code for testing all conditions tests together before the code for all conditional branches. Switch'es are good by the fact that the conditions they test is simple and don't require declaring unique labels: they are then more compact, and easier to maintain. I do like switch'es.
I don't care at all if they are finally compiled as computed gotos (indirection via an array of label pointers), or series of if-tests and many jumps (the same also applies to if/elseif/else/end blocks that can compile using all the same options):
This is a compiler implementation detail anyway. For programmers in alny language, it has to be concise, clean, easy to read and manage for refactoring. Lua can perfectly be built for the programmer's ease of understanding, any compiler will be able to find all the possible tricks itself.
