Should `const FnMut` require `const FnOnce`?

I am opening this issue so we don't forget to make a decision on this before stabilizing const traits.

It is unclear whether const FnMut should require const FnOnce or not. In other words, should the super trait bound on FnMut be const trait FnMut: FnOnce, or const trait FnMut: [const] FnOnce?

It is clear that const Fn should require const FnMut, which is enforced in https://github.com/rust-lang/rust/pull/147939. However, the situation is less clear whether const FnMut should require const FnOnce. For example:

fn only_const_fn_mut() -> impl FnOnce() + const FnMut() {
    let mut thing = NonConstDestruct;  // Doesn't implement const Destruct
    const move || do_something(&mut thing)
}

In this hypothetical code, assuming that const closures were to be implemented, it makes some sense for the closure to implement const FnMut (since all it's doing is mutating thing), but the closure cannot implement FnOnce, since calling it via FnOnce would require running the destructor of thing. This use case can only be supported if const FnMut does not require const FnOnce.

On the other hand, if const FnMut were to not require const FnOnce, then user code would be unable to directly pass a const FnMut closure to a function that expects a const FnOnce without some workaround (e.g., wrapping the closure in another closure). This seems annoying and confusing to users. This is a point in favor of making const FnMut require const FnOnce.

See also some prior discussion on zulip.

Start by reading the issue's proposed const FnMut and const FnOnce supertrait alternatives, then review the linked Zulip discussion and Rust pull request #147939 for context. Done means reaching and documenting a decision on whether const FnMut requires const FnOnce before const traits are stabilized.