> ... defending a sunk cost, rather than than advocating for the best API ...
If you really go all-in on the Cypress API, writing custom commands, etc, not having to mess around with async/await is really nice. It's a strong point for onboarding QA devs, who might not be familiar with JS, Promises etc. This is also one of the major drawbacks - for any proficient JS devs, who are used to async/await and the usual business, the obvious question is "why isn't this just standard JS?". I definitely had the same feeling when I first starting writing Cypress tests.
> It would be hard for Cypress to change the API now ... I doubt Cypress team would design the API this way if they started again today ...
I am not sure of the technical complexity or priority of decoupling Cypress from the Chainable API. I'd assume the complexity is not supporting async/await, but supporting it alongside the current API.
I think the ideal case would be loosening the coupling between all the parts of Cypress, that would allow someone (either the Cypress team or a third party) to write their own selecting/assertion API, and they could then optionally write it with chaining, async/await, or something else. Perhaps even create bindings for another language (currently Cypress is JS only, since a lot of the code executes in the browser, unlike Playwright, where everything is via the CDP - another example where one of the main strengths of Cypress can also be a weakness).
Hopefully this gives you some more context and insight! My goal is better testing tools for the web, I think both Cypress and Playwright are solving this problem in different ways with a different philosophy. I'm glad to see so much innovation in the space, I hope we can keep pushing things forward.