Assume the operand of the expression co_await promise.final_suspend() has std::always_suspend type. That means after evaluating the associated await-ready expression, the coroutine should be considered in a suspending state and then transfer the control to the caller or resumer after evaluating the await-suspend expression.

If the result of await-ready is false, the coroutine is considered suspended.

Then invoking resume() for the coroutine will result in a crash in most major implementations(GCC, clang). But, invoking destroy() is ok. The current draft is underspecified for what the status is.

There are only little hints in section [support.coroutine]
support.coroutine#coroutine.handle.observers-3

true if the coroutine is suspended at its final suspend point, otherwise false.

support.coroutine#coroutine.handle.resumption-2

Preconditions: The coroutine is not suspended at its final suspend point.

If merely according to what [expr.await#5] says, the coroutine should be considered in a suspending status. IIUC, the preconditions above intend to state that when calling resume for a coroutine after evaluating the associated await-suspend expression for the final suspend point, the coroutine is as if it's not in suspending status at this point. Should we make the rule be a normative rule defined at [dcl.fct.def.coroutine]?