Reading [readable.traits] we have the following definitions for how the source of iter_value_t may be generated:

The first provides a specialisation if the type has a typedef value_type, and uses value_type:

>template<has-member-value-type T>
>struct indirectly_readable_traits<T>
>: cond-value-type <typename T::value_type> { };

The second provides a specialisation if the type has a typedef element_type:

>template<has-member-element-type T>
>struct indirectly_readable_traits<T>
>: cond-value-type <typename T::element_type> { };

The third provides a specialisation if BOTH value_type and element_type are provided, and does not contain a definition for value_type:

>template<has-member-value-type T>
>requires has-member-element-type <T>
>struct indirectly_readable_traits<T> { };

The express intent is that a type that defines both value_type and element_type not meet the indirectly_readable concept, and thus shouldn't meet the input_iterator concept either. LWG issue 3541 addressed the earlier ambiguity with types that had both value_type and element_type by explicitly making it fail to meet the requirements.

On 29 April 2025 02:44:42 BST, "F. v.S. via Std-Discussion" <std-discussion_at_[hidden]> wrote:
>Per current specification of std::iter_value_t, if a class type with proper member type value_type meets some C++17 iterator requirements (Cpp17InputIterator or a stronger one) but has an inconsistent member typedef element_type (e.g. void), it doesn't satisfy the std::input_iterator concept (or a stronger one) because std::iter_value_t isn't valid for that type.
>
>Is such treatment intended? If not, perhaps there should be an LWG issue to specify that I::element_type is not detected when I::value_type is a valid type.
>
>Thanks,
>F.v.S.