No, that entirely loses the expected performance and clarity of a switch. Remember that "arbitrary types" in C are not so exotic. A simple byte-by-byte comparison will do, skipping over any struct padding. Compilers today will generate code that uses various strategies (tree, hash, etc.) to do the comparisons, and it would be awful to impede that via an arbitrary user-specified comparison function. Doing a linear scan of every case, O(n*m) for the number of cases and the lengths of the strings, defeats the whole point of using a switch. One can already do that with cascading "if".
For strings, the simplest syntax is to have the new behavior triggered by passing a pointer to any type which can be evaluated as an integer. That last requirement makes scanning for a terminator work in an obvious way. This does seem to lose the possibility of comparing arrays that are not NUL terminated, but that isn't the use case that people are dying for.
Since the vast majority of the desire to switch on strings is involving ASCII keywords, it would be reasonable to prohibit gcc-style ranges (like "case 1 ... 4:") for non-ASCII strings. This means that the strings can be treated like giant integers stored in big-endian form. (after the NUL, treat it as more NUL going on forever) Clearly it is well-understood how to switch on integer values, and thus we can switch on strings.
Right now the ways to switch on strings are terrible. If they are short, they can be memcpy into long long. With gcc one can use the computed goto extension, plucking values out of a table via bsearch or via a perfect hash function generated by something like gperf. It's all really miserable, leading low-performance programmers to just use cascading "if".
