I believe the presence or absence (and the spelling) of associated constraints influences partial ordering, before the shape of the target type is even considered. So, this does not appear to be an editorial change.

@CaseyCarter , @jwakely ?

drop_view was added later by P1035R7, so the inconsistency could just be an oversight, but I agree it's not editorial.

It looks like that take_view guide and this one are the only constrained guides for view adaptors:

template<input_range R>
    split_view(R&&, range_value_t<R>)
      -> split_view<views::all_t<R>, single_view<range_value_t<R>>>;

take_view significantly predates drop_view. When we added take_view, the range constraint was necessary to ensure that iterator_t<R> was well-formed in iter_difference_t<iterator_t<R>>.

P1035 constrains iterator_t itself with range, and added range_difference_t<R> as a range-constrained alias for iter_difference_t<iterator_t<R>> so neither drop_view nor take_view require this constraint. P1035 had blanket editorial instructions to replace iter_difference_t<iterator_t<R>> with range_difference_t<R>, but it didn't occur to the authors to also audit constraints elsewhere and remove any we'd made extraneous.

TLDR: Changing this would have no normative effect, but it falls into that grey area where we need experts to attest to that. I suggest filing an LWG issue.

Handled by LWG3447.

Status: WP

This can be closed.