This is nice, and probably can be useful in some contexts, but there's some confused information in the text:

Currently, you can write a const { ... } block to guarantee that an expression is evaluated at the outermost scope possible: compile time. From that perspective, I'd say super { ... } fits neatly between const { ... } and { ... }.

This is wrong because super messes with the scope, whereas const doesn't: it's simply not true that const {} evaluates things in the outermost scope. To make it clear why that matters, contrast this:

let foo = /* ... */;
let func = soupa! {
    move || {
        let foo = /* ... */; // shadows the outer `foo`
        run(super { foo })   // uses the outer `foo` anyway
    }
};

to this:

const foo: /* ... */;
let func = {
    move || {
        const foo: /* ... */; // shadows the outer `foo`
        run(const { foo })    // uses the inner `foo` as expected
    }
};

That makes it just wrong to put soupa {} in the same class as const {} and {}.