Proposed resolution:

This wording is relative to N4958.

1. Modify [ranges.syn] as indicated:

   #include <compare>              // see [compare.syn]
   #include <initializer_list>     // see [initializer.list.syn]
   #include <iterator>             // see [iterator.synopsis]
   
   namespace std::ranges {
     […]
     // [range.utility.conv], range conversions
     template<class C, input_range R, class... Args> requires (!view<C>)
       constexpr C to(R&& r, Args&&... args);                                          // freestanding
     template<template<class...> class C, input_range R, class... Args>
       constexpr auto to(R&& r, Args&&... args);                                       // freestanding
     template<class C, class... Args> requires (!view<C>)
       constexpr auto to(Args&&... args);                                              // freestanding
     template<template<class...> class C, class... Args>
       constexpr auto to(Args&&... args);                                              // freestanding
     […]
   }
   

2. Modify [range.utility.conv.to] as indicated:

   template<class C, input_range R, class... Args> requires (!view<C>)
     constexpr C to(R&& r, Args&&... args);
   

   -1- Mandates: C is a cv-unqualified class type and does not satisfy view.

   […]

3. Modify [range.utility.conv.adaptors] as indicated:

   template<class C, class... Args> requires (!view<C>)
     constexpr auto to(Args&&... args);
   template<template<class...> class C, class... Args>
     constexpr auto to(Args&&... args);
   

   -1- Mandates: For the first overload, C is a cv-unqualified class type and does not satisfy view.

   […]

[ 2023-10-30; Reflector poll ]

Set priority to 3 after reflector poll.

In order to solve issues in LWG 3787 and LWG 3847 that the template parameter C can be specified as an unreasonable type, ranges::to adds a Mandates that requires C to be a cv-unqualified class type.

However, the earliest requirement that C not be a view was still imposed by the constraints of function signatures, although it is unclear why Constraints were used in the first place, such a way of kicking out the function candidate does bring undesirable hard errors and poor diagnostics (demo):

#include <ranges>

int main() {
  auto iota = std::views::iota(0, 10);
  auto take = std::ranges::to<std::ranges::take_view>(iota, 5);  // hard error in function body
  auto drop = iota | std::ranges::to<std::ranges::drop_view>(5); // poor diagnostics
}

I think consistent use of Mandates for template parameter C is more appropriate, as static_assert provide clearer and more readable diagnostics.