The mention of making CPS (continuous passing style) compiler integration possible is something very important. That would enable Go- or Kotlin-like coroutines to land in the language, which is sorely needed to end the async wars between stdlib's horrible asyncdispatch module, and Status.im's barely documented Chronos async/await implementation.

There has been a more-or-less working CPS implementation for Nim for a few years now:

https://github.com/nim-works/cps

https://github.com/nim-works/cps/tree/master/docs

Nobody seems to care though, as it has gained no traction at all and it has been mostly ignored by the core team.

The issue with the CPS implementation here is that the compile times are too slow, and there are several restrictions due to flaws and limitations of the compiler. That's the reason CPS in the compiler is a big deal. I've used the CPS lib you're showing before, and it's very nice, but the compile times make it absolutely useless for productive development.

that "just" strongly underestimates the value add of those two features!

The features already exist and the topic doesn't indicate how they would get any better.

Having a structured IR could make it pluggable to the MLIR ecosystem, for example.

Just because it has IR in the name doesn't mean there's any connection. If you want to emit MLIR using nim you can already do this using MLIR's C API, if you want to map nim ast to to existing MLIR IR you can already do this if you provide the necessary control flow analysis, if you want to map nim ir to MLIR you will still need a lowering or nim dialect.