Proposed resolution:

This wording is relative to N4885.

1. Modify [readable.traits] p1 as indicated:

   […]
   template<class T>
     concept has-member-value-type = requires { typename T::value_type; }; // exposition only
   
   template<class T>
     concept has-member-element-type = requires { typename T::element_type; }; // exposition only
   
   template<class> struct indirectly_readable_traits { };
   
   […]
   
   template<has-member-value-type T>
   struct indirectly_readable_traits<T>
     : cond-value-type<typename T::value_type> { };
   
   template<has-member-element-type T>
   struct indirectly_readable_traits<T>
     : cond-value-type<typename T::element_type> { };
   
   template<has-member-value-type T>
     requires has-member-element-type<T>
   struct indirectly_readable_traits<T> { };
     
   template<has-member-value-type T>
     requires has-member-element-type<T> &&
              same_as<remove_cv_t<typename T::element_type>, remove_cv_t<typename T::value_type>>
   struct indirectly_readable_traits<T>
     : cond-value-type<typename T::value_type> { };
   […]
   

[ 2021-06-07 Approved at June 2021 virtual plenary. Status changed: Voting → WP. ]

[ 2021-04-20; Reflector poll ]

Set status to Tentatively Ready after seven votes in favour during reflector poll.

Following the outcome of LWG 3446, a strict implementation of std::indirectly_readable_traits isn't SFINAE-friendly for types that have different value_type and element_type members due to the ambiguity between the has-member-value-type and has-member-element-type specialisations. Other traits types are empty when requirements aren't met; we should follow suit here.