It looks like a fun project, but I'm not sure what this adds to the point where people would actually use it over C or just going to Rust.

Nim is a full, independent modern language that uses C as one of its backends. It has its own runtime, optional GC, Unicode strings, bounds checking, and a huge stdlib. You write high-level Nim code and it spits out optimized C you usually don't touch.

Here’s a little comparison I put together from what I can find in the readme and code:

    Comparison          ZenC           Nim
    
    written in          C              Self-Hosted
    targets             C              C, C++, ObjC, JS, LLVM (via nlvm), Native (in-progress)
    platforms           POSIX          Linux, Windows, MacOS, POSIX, baremetal
    mm strategy         manual/RAII    ARC, ORC(ARC with cycle collector), multiple gc, manual
    generated code      human-readable optimized
    mangling            no             yes
    
    stdlib              bare           extensive/batteries-included
    
    compile-time code   yes            yes
    macros              comptime?      AST manipulation
    
    arrays              C arrays       type and size is retained at all times
    strings             C strings      have capacity and length, support Unicode
    bounds-checking     no             yes (optional)

another is that it only has C runtime requirement, so no weird runtime stuff to impelement if youd say want to run on bare metal..you could output the C code and compile it to your target.

    fn main() {
        comptime {
            var N = 20;
            var fib: long[20];
            fib[0] = (long)0;
            fib[1] = (long)1;
            for var i=2; i<N; i+=1 {
                fib[i] = fib[i-1] + fib[i-2];
            }

            printf("// Generated Fibonacci Sequence\n");
            printf("var fibs: int[%d] = [", N);
            for var i=0; i<N; i+=1 {
                printf("%ld", fib[i]);
                if (i < N-1) printf(", ");
            }
            printf("];\n");
        }

        print "Compile-time generated Fibonacci sequence:\n";
        for i in 0..20 {
            print f"fib[{i}] = {fibs[i]}\n";
        }
    }

The Zig equivalent of the above comptime block just be:

    const fibs = comptime blk: {
        var f: [20]u64 = undefined;
        f[0] = 0;
        f[1] = 1;
        for (2..f.len) |i| {
            f[i] = f[i-1] + f[i-2];
        }
        break :blk f; 
    };

I'm writing my own programming language that tries "Write like a high-level language, run like C.", but it does not have manual memory management. It has reference counting with lightweight borrowing for performance sensitive parts: https://github.com/thomasmueller/bau-lang

For some niches the answer is "because the convenience is worth it" (e.g. game jams). But I personally think the error prone option should be opt in for such cases.

Or to be blunt: correctness should not be opt-in. It should be opt-out.

I have considered such a flag for my future language, which I named #explode-randomly-at-runtime ;)

When reading working code, it doesn't matter whether the language mode allows variable reassignment. It only matters when you want to change it. And even then, the compiler will yell at you when you do the wrong thing. Testing it out is probably much faster than searching the codebase for a directive. It doesn't seem like a big deal to me.

So, having an async function run on a separate thread from those functions that are synchronous seems a viable way to achieve the underlying goal of continuous processing in the face of computations that involve waiting for some resource to become available.

I will agree that inspired by C#’s originating and then JavaScripts popularization of the syntax, it is not a stretch to assume async/await is implemented with an event loop (since both languages use such for implementation).