Proposed resolution:

This wording is relative to N4986.

1. Modify [move.iterator] as indicated:

   namespace std {
     template<class Iterator>
     class move_iterator {
     public:
       […]
       constexpr move_iterator() requires default_initializable<Iterator> = default;
       […]
     private:
       Iterator current = Iterator();   // exposition only
     };
   }
   

2. Modify [move.iter.cons] as indicated:

   constexpr move_iterator();
   

   -1- Effects: Value-initializes current.

[ 2024-08-02; Reflector poll ]

Set priority to 3 after reflector poll. Six P0 (tentatively ready) votes but one for NAD: "design change, needs paper. Not constraining this seems to be intended by p2325r3. Even if we want to constrain it, why `default_initializable` rather than just `is_constructible_v`?" Author of p2325r3 had no such intent and voted P0. Issue submitter used `default_initializable` to align with `forward_iterator` requirements, but would not object to implementers using `is_constructible_v` for backported DRs.

Although it is unclear why P2325 did not apply to move_iterator, there is implementation divergence among the current libraries (demo):

#include <istream>
#include <iterator>
#include <ranges>

using R = std::ranges::istream_view<int>;
using I = std::ranges::iterator_t<R>;
using MI = std::move_iterator<I>;
static_assert(std::default_initializable<MI>); // libstdc++ passes, libc++ fails

As libc++ additionally requires that its default constructors satisfy is_constructible_v<Iterator>.

Although this is not current standard-conforming behavior, such constraint does make sense since move_iterator only requires the underlying iterator to be input_iterator which may not be default_initializable.