One of the bigger problems of transpiling to C is inheriting its oddities, such as the definition of overflow (or lack thereof) depending on the signedness of integers, etc., etc. Personally, I'd argue that transpiling to C combines most of the downsides of a new language with most of the downsides of C. I will admit, though, that the zero-effort FFI support of the approach is quite enticing.
you can use C to create any system you want including your preferred overflow, signedness, etc. Yes, it's that powerful. Then transpile to what you've created... which would still be transpiling to C. C lives outside the box, try to think that way.
Without compiler extensions galore, no C is not that powerful. Until C11, you couldn't even control alignment without hacky union workarounds that weren't great. You simply can't model exotic integer types in C like you can in LLVM IR. You can't disable struct padding without a GNU extension. The variance and portability of libc is pretty annoying too; you'd be surprised how many GNUisms you thought were in the spec. But worst of all, C's integer behavior is extremely unintuitive and basically force you to use case every operand and every binOp result to ensure desired behavior in all cases. You totally could transpile to C, but you'll basically have to master the C spec & its edge cases, write everything out in single-static-assignment form with explicit casts everywhere, avoid most of libc, use at least C11, accept some shortcomings, and avoid using most C language constructs and basically write assembly in C. Either do all that, or you'll inherit some of the quirks and shortcomings of C (and have your C compiler misinterpret your code). And even then, it probably won't optimize that well. Please, just output LLVM IR or something.
Yes, that's how I see it. C can do anything - albeit ardously - and in the process of writing that transpiler to C in C I hope to make a huge leap in my understanding of C's model and of constructs in general.
