I’m curious if someone can sell me, practically, in relatively few words, what that would gain us compared to Promises today.

That link wasn’t sufficient to teach me. I’m a bit dense. :(

Basically, the current promises take a shortcut. If your promise returns a promise, the two promises are automagically combined into one promise.

    foo
    .then(() => returnsAnotherPromise())
    .then(() => { /*only receives the nested promise*/})

The correct solution would not automatically flatmap

    foo
    .then(() => returnsAnotherPromise())
    .then(innerPromise => { 
      innerPromise.then(() = {}) //now we have access to the nested promise
    })

The second API is easier to statically type (creating a type that automatically, but conditionally removes a type is not necessarily0 easy). The second API makes some abstractions easier. The second API more intutitive for most people new to promises (I've seen it done a lot -- especially a few years ago). The second API allows you to interface with other monads without constantly having to do a special conversion any time you touch a promise.

The current API is way more ergonomic for most current developers.

In any case, it seems like there should a way to create your own proper monad promises along with an interface to normal promises when needed.

I’m surprised to discover that promise flattening. Never noticed it before. Thanks!