Currently, projected is a wrapper of the implementation type regardless of whether Proj is identity.

Since identity always returns a reference, this prevents projected<I, identity> from fully emulating the properties of the original iterator when its reference is a prvalue.

Such non-equivalence may lead to unexpected behavior in some cases (demo):

#include <algorithm>
#include <ranges>
#include <iostream>

int main() {
  auto outer = std::views::iota(0, 5)
             | std::views::transform([](int i) {
                 return std::views::single(i) | std::views::filter([](int) { return true; });
               });
  
  for (auto&& inner : outer)
    for (auto&& elem : inner)
      std::cout << elem << " "; // 0 1 2 3 4 
  
  std::ranges::for_each(
    outer,
    [](auto&& inner) {
      // error: passing 'const filter_view' as 'this' argument discards qualifiers
      for (auto&& elem : inner)
        std::cout << elem << " ";
    });
}

In the above example, ranges::for_each requires indirect_unary_predicate<Pred, projected<I, identity>> which ultimately requires invocable<Pred&, iter_common_reference_t<projected<I, identity>>>.

According to the current wording, the reference and indirect value type of projected<I, identity> are filter_view&& and filter_view& respectively, which causes its common reference to be eventually calculated as const filter_view&. Since the former is not const-iterable, this results in a hard error during instantiation because const begin is called unexpectedly in an unconstrained lambda.

It seems like having projected<I, identity> just be I is a more appropriate choice, which makes the concept checking really specific to I rather than a potentially incomplete iterator wrapper.