If someone wanted to replace C, they are likely seeking to do so for reasons intrinsic to C, such as the risk of memory over/underflow, use after free, problematic numeric promotion, lack of proper strings and bools, etc.

Transpiling to C is the worst possible way of trying to address these issues. If you write `x + y` in your newlang, and that transpiles to `x + y` in C, you have simply inherited all of C's implicit type conversion nonsense. If, alternatively, you write a whole bunch of machinery to ensure x + y is always safe, congratulations, you're now writing a VM in C, which is even harder to get right and do safely. If you're trying to reduce your use of C, and you wind up maintaining a VM in C, I rather think you've somewhat catastrophically failed in your objective.

It's for this reason that languages trying to replace C don't generally transpile to C, despite your claim. The biggest C replacement candidates right now are Zig and Rust, both of which target LLVM IR, not C. There are precious few use cases where you'd want to leave C in as an unnecessary, problematic middleman, when LLVM IR is available.

Similarly, transpiling to JS inherits all of JS' baggage and issues, of which much has accumulated in the last thirty years. It would be an undoubted improvement to be able to bypass that layer when it isn't useful, regardless of one's opinion on JS.

Just as C replacements compile to pure LLVM IR, a JS replacement should be able to compile to pure WASM.