I agree. The comment is correct in that it sort-of violates the "purity" of std::indirect that it has this pathological in moved-from state, but it's only an issue when directly using moved-from objects, which is something you essentially never do. Exactly what you say, "in practice" this never happens. Throwing the move constructor out because of it would be throwing out the baby with the bathwater.
std::variant has a similar issue with valueless_after_exception, which given the semantics of the language, it has to have. But similarly, this essentially never happens in practice, and I've never encountered a bug with a valueless std::variant.
For std::variant, are you sure that it is similar? I have heard of alternatives to std::variant that avoids needing the valueless_after_exception, like what Sean Baxter proposed in a library or something, and Boost might also have something like it.
It is similar in that the valueless state isn't absolutely necessary, but avoiding the valueless state in general is not free and it seems the committee was unwilling to force implementations to incur that cost.
The docs for Boost.Variant state that avoiding a valueless state requires some kind of additional storage beyond that strictly required for the intended value. In the current implementation this means that assignment may allocate (modulo optimizations described further down the page) [0], which is obviously unacceptable for some use cases.
The proposal for std::indirect and std::polymorphic describes similar costs for avoiding a valueless state, though for moves instead of assignment [1]:
> Without a valueless state, moving indirect or polymorphic would require allocation and moving from the owned object. This would be expensive and would require the owned object to be moveable. The existence of a valueless state allows move to be implemented cheaply without requiring the owned object to be moveable.
Presumably the committee made a similar decision with respect to a valueless state for std::variant as they did for std::polymorphic/indirect.
std::variant has a similar issue with valueless_after_exception, which given the semantics of the language, it has to have. But similarly, this essentially never happens in practice, and I've never encountered a bug with a valueless std::variant.