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

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.