A feedback round was started on the mailing list on May 7, 2024.
https://lists.isocpp.org/lib-ext/2024/05/27310.php

Summary:

• Reviewers discussed the name of the proposed member function.
  • Multiple reviewers preferred the alternative name view().
  • A reviewer pointed out that the existing standard library facilities basic_stringbuf and basic_istringstream have view() member functions.
  • A reviewer expressed support for having the expression st.view() return a view of the entire string. The reviewer floated providing a separate subview member function alongside a zero-argument view if there was not enough support for renaming subview.
  • A reviewer rejoined that the primary use case for the member function as is as a more efficient replacement for substr, and it shouldn't be named to optimize for the rare and incidental case of using it to obtain a view to the entire string (which can already be done by constructing a std::string_view).
• Reviewers discussed the member function's reference qualification.
  • A reviewer called the facility a footgun without lvalue reference-qualification, because auto x = getstring().subview(...); dangles.
  • A reviewer pointed out that the basic_streambuf and basic_istringstream view member functions are not lvalue-qualified.
  • A reviewer replied that qualifying them may not have been considered when they were standardized.
  • A reviewer pointed out that adding lvalue reference qualification rules out an example like foo(getstring().subview(begin, end)).
  • A reviewer replied that LEWG should adjudicate whether it's acceptable to make users use the workaround of { const std::string& s = getstring(); foo(s.subview(begin, end)); }.
  • A reviewer claimed that the member function should not be lvalue-qualified because doing so conflates value category with lifetime.

The paper is deferred to meeting review.