Would it be more appropriate to remove all constexpr qualifiers from this section (although end() can be constexpr by its implementation)?

I think some or all constexpr specifiers in [range.istream.view] may be unintended. But they don't seem defective and work in some edge cases. Can we find a case where constexpr triggers additional instantiation which can be ill-formed for some incomplete types?

#include <iostream>
#include <ranges>

constexpr auto sent = std::views::istream<int>(std::cin).end();

#include <iostream>
#include <ranges>

struct Foo {
    template<class CharT, class Traits>
    friend constexpr std::basic_istream<CharT, Traits>& operator>>(std::basic_istream<CharT, Traits>& is, Foo) {
        return is;
    }
};

static_assert([] {
    auto v = std::views::istream<Foo>(std::cin);
    auto it = v.begin();
    return true;
}());

The status quo is inconsistent as there're non-constexpr functions. It's possibly reasonable to add constexpr to both operator++s and operator*, but not to the operator==.

But they don't seem defective and work in some edge cases.

Although they can work in some edge cases, these cases are useless and unreasonable in my opinion.
Could you come up with some really meaningful cases?

The constexpr on the constructor and end definitely make some sense (although not so much). E.g. the following is currently well-formed, and I don't think it make much sense to make it ill-formed.

std::generator::end is completely constexpr-able but it doesn't, because coroutine, like istream, is completely a run-time thing. Adding constexpr to it is of debatable value in my opinion.

This is not an editorial concern, it seems.