On the end, i'm going to reintroduce internal promise impl for js runtime (instead of directly using js/Promise), for to be able to inspect the promise state (the builtin js/Promise is very opaque) but i have a dilemma, I have the opportunity to make it work in the same way as CompletableFuture (without automatic promise unnesting, I mean properly implement map and mapcat) but this clearly breaks current behavior, and this throws me back to make this change (cc @mccraigmccraig) The new impl is already committed on master branch and still works in the same way as js/Promise, but allows inspection, I mean knowing the state and synchronous access to the value, without blocking just access if it is available...)

the api has the auto-unnesting then and the non-auto-unnesting then' already... wouldn't this just be fixing the cljs brokenness of the then' fn?

yep, but if the people are hard relying on this broken behavior will have probably a bunch of code broken for next release

Obviously I will increase the major version... I'm also considering expose a google closure define, that will allow set the behavior globally

that will let people to decide which behavior to use in the codebase

hmm... the way i ended up working around the brokenness worked fine on clj too, so fixing cljs would not break anything... don't know how common that experience is though

(i put promise values in a wrapper type so they didn't get auto-unnested)

yep, this is the problem, Im also don't know how the people use it, so I guess the safest way is provide a compiler define that allows to switch

do i recall correctly that auto-unnesting is the thing which stops js promises from being a monad?

yep

... which makes composition awkward... so it seems to me that removing auto-unnesting as the default behaviour would make promesa easier to use, and providing an option to support the old behaviour would mitigate the difficulty of the change

yep, this is the change I going too look into this days