Does the future returned from std::async with the launch::deferred policy block in the destructor?

In the description of the std::async it is said that:

If the std::future obtained from std::async is not moved from or bound to a reference, the destructor of the std::future will block at the end of the full expression until the asynchronous operation completes, essentially making code such as the following synchronous:

std::async(std::launch::async, []{ f(); }); // temporary's dtor waits for f()
std::async(std::launch::async, []{ g(); }); // does not start until f() completes

(note that the destructors of std::futures obtained by means other than a call to std::async never block)

This statement is confusing, and I don't clearly understand what should be the behavior in case of std::launch::deferred policy. Ok, the experiment shows that it doesn't block, but I wonder whether the standard explicitly says that the future returned from std::async with the std::launch::deferred policy doesn't block in destructor.

This opens another follow-up question regarding the default policy: if the future returned from std::async blocks in destructor in case of std::launch::async and doesn't block in case of std::launch::deferred, that should lead to very inconsistent behavior in case of the default (std::launch::async | std::launch::deferred) policy. Recently I was asking of the semantics of std::async with default launch policy: What is the semantics of std::async with automatic (launch::async|launch::deferred) launch policy?, this example confuses me even more, and the applicability of the pattern where we don't explicitly know the platform selection of the policy, is very questionable.