Is this a reinvention of async/await?
One slightly different perspective is that the implementations of generators and async/await are just very similar monad transformers of two different monads (Iterable/"List" versus Future/Promise/Task). If you've already built one of these monad transformers you can built the other on top of it because they share a lot of the basics of being a monad transformer. In most cases today's languages had generators long before they had async/await so often generators or generator-like output is an implementation detail of async/await. It's not hard to imagine a world where async/await was the more common early implementation and generators used async/await an implementation detail. The abstractions are definitely related in interesting ways even if it's mostly only Haskell and a few others that decided to take the abstraction all the way "to the top" in their syntax. (Haskell do-notation being the same for whether you are working with Iterables or Futures or anything else that fits the abstraction of a monad.)
It actually is: Promises have implications for event loop scheduling that preclude async (which implicitly returns a Promise) from providing synchronous semantics. Everything else you’re saying is mostly right (I’ll leave it to other folks to nitpick the monadic details, and just note that nits are there for the picking), but I think it’s important not to totally obscure this essential detail when observing that they’re otherwise closely related concepts.
Those also generally are implementation details of the chosen Promise/Futures/Tasks transformer model. The monad itself says nothing about how things are plumbed, event loops are just one common/useful way to plumb it.
C# Tasks run synchronously by default, on the same thread, and there is no required event loop (but you may need to interoperate with the SynchronizationContext for one). (.NET for better and worse uses a heavier threading abstraction than microstasks/green-threads.) It's often a common misconception for .NET developers that Tasks are always async and run in other threads. You can write code with synchronous semantics in C# async/await. It requires care and understanding, but it is possible.
One of the reasons async/await is so complicated in Python is that you can bring your own plumbing. The most common plumbing tools that are winning are event loop based, but there are other options, some of which allow synchronous semantics. Similarly, Rust's async/await support is nearly as complicated, just with fewer competing third party library options.
Thinking about Futures/Promises/Tasks from a JS-heavy perspective (which I can presume by your preference for the name Promises) where everything has to be browser-mediated microtasks in an event loop makes it really easy to mistake this one monad tree (of microtasks on an event loop) for the overall forest of this large monad family (with a number of implementations under the hood).
You’re presumably coming from a place where you think it’s helpful to educate about the generalization, and that’s fine. But I’d suggest that when someone is clearly informed enough on the topic to clarify a language-specific nuance that diverges from the generalization, it probably isn’t because they’re ignorant, and it’s probably going to come off as rather condescending to respond as if they are.
That said, you've now called me condescending twice and I don't appreciate ad hominem attacks and will not engage with you further on this thread. I hesitated to even write this comment. (I also don't engage by creating "sock puppet" accounts, and I see the other comment accusing me of "sock puppeting" as a third, further unwarranted, ad hominem attack in this thread.) I don't think I need to reread the thread to know what happened in the communication mistakes, but I would suggest that you try to refrain from using attacks to deal with what were simple communication mistakes in the future.
I didn’t accuse you of creating a sock puppet account. I observed that the other response came from a newly created account, with that single comment posted about the same time. That observation wasn’t addressed to you, it was addressed to that new account.