@syg @lars-t-hansen I'm in the process of writing tests for this feature and I'm finding that this issue keeps coming up. Can I get some thoughts here?

Also, I want to hear from @ljharb as well.

This is a good catch; async function was explicitly designed to never throw a sync exception, including from default arguments - it seems ideal to follow the same precedent here.

My current thinking is that validation errors should reject the promise. I'll move the discussion of eagerly returning "not-equal" off of this issue. Found SYNC-RESOLVE.md from 3 years ago where we came down to not having any sync "not-equal" result, though now I have renewed worries about the performance.

Though to be clear this is a needs-consensus change. I'll make a PR to the agenda for a deprioritized item.

@ljharb I've chatted with some more folks since #28 (comment) and @jridgewell pointed me to https://2ality.com/2016/03/promise-rejections-vs-exceptions.html, which seems well reasoned. That argues that invalidation errors should fail fast and remain synchronous exceptions. Are there API examples where invalidation errors are turned into Promise rejections?

Yes, Promise.all().

As another counterpoint to the status quo, I was pointed to https://www.w3.org/2001/tag/doc/promises-guide#always-return-promises.

And Promise.any()

Looks like we have solution