I agree it would be too disruptive. But there is no "forever", for example,
C++17/20 removed a lot of old facilities like auto_ptr. What's wrong with
removing some old facility if there's a suitable replacement, and it's been
long enough? Otherwise C++ becomes a garbage dump.

So, rvalue assignment can be deprecated (with some exceptions) and
as_lvalue can be added now, then rvalue assignment can be disabled after
long enough.

On Sunday, October 9, 2022, Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On Sat, Oct 8, 2022 at 11:38 AM Lee Shallis via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>>
>> Arthur I disagree, anything of the form "func() = ..." or is just bad
>> form
>
> That ship sailed before C++98 was even standardized. `*it =
> something;` is functionally equivalent to `it.operator() =
> something;`. So it's been a part of C++ since forever. Also,
> `vector<bool>` has been a part of C++ since forever. As has
> `container::front/back` returning non-`const` references.
>
> You can call it bad form if you like, but it is normal C++. I highly
> doubt the committee is going to break the entirety of the standard
> library iterator and container model (not to mention all of the other
> code out there that works) because some people believe it is
> "confusing to newbies".
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>