Forgive me if I missed something obvious, but I'm not sure I see the motivation behind this proposal. std::async will always be a possibly exception-prone function because there simply is no way to guarantee that the system will have the resources available to start a thread (if required) or allocate a shared state. While I'm no expert on the internal workings of the concurrency library, I'm not sure your proposed implementation is exception free either - the act of creating a shared state for your default-return-value promise/future pairing may be dynamically allocated and so may throw std::bad_alloc. In any case, should async fail due to some system or implementation issue, I'd argue that it's better to fail immediately and loudly.

Consider someone using this code. They call async_noexcept, get a future, and since nothing goes wrong they reasonably assume that the result of their call will be available in that future in due course. They may then go on to do X, Y, and Z and get to the other end of the program before calling get() on the future and only then learning that their initial async failed and they did all this extra work for nothing. Would your proposal mandate that as basic error handling, a user is also expected to do some investigation of their obtained future and try to deduce whether it failed without opening it up to try and get() it?

I'm not a big fan of just swallowing every possible exception either, or mandating that the user provide some meaningless default value for the error case - that pattern has never worked for everyone and one of the benefits of std::optional is that we don't have to do it any more. But that aside - what's the benefit of this proposal to outweigh the additional boilerplate it pushes onto the user?