I'm sure I missed enforcing this requirement on the type and value category of the assignment expression for all of the assign_range implementations, we should audit.

I believe our assignment expressions are fine:

For vector<bool, A>, we're using copy-initialization instead of assignment. I think this is still conforming - but if I'm wrong, we need to swich to use bool _Tmp; _Tmp = *_First;.

Note that std::is_assignable_v<Int&, std::ranges::range_reference_t<std::vector<int>&>> is true for your example. So I guess this is arguably a defect in the standard that it's overly strict to use assignable_from in Mandates of assign_range functions. Perhaps it would be OK to just reuse the well-formedness of declval<T&>() = *ranges::begin(rg).
(is_assignable_v can be overly strict when the iterator of rg dereferences to a prvalue, the element type of rg is not movable, and the operator= takes that element type by value.)

For vector<bool, A>, we're using copy-initialization instead of assignment. I think this is still conforming - but if I'm wrong, we need to swich to use bool _Tmp; _Tmp = *_First;.

STL/stl/inc/vector

const bool _Tmp = *_First;

_Container_compatible_range<bool> guaranteed this is ok, right?

Also, common_reference_with in assignable_from doesn't seem correct to me. I found that it was originally added in ericniebler/stl2#150 (although significantly modified in C++20).

I think when we use assignable_from to constrain something, it just corresponds to some assignment expressions where common_reference_t is unnecessary.

We talked about this at the weekly maintainer meeting and we think that adding a bunch of static_asserts to enforce these Mandates is quick and easy, with the disclaimer that such static_asserts imply nothing about the moral worth of the Standard's yucky requirements 🤮 (which @CaseyCarter wishes he could take back - I am omitting an entire glorious rant about the assignable_from concept here 😹).

Note that string::assign_range doesn't have Mandates for this, not sure if this deserves an LWG.

Note that string::assign_range doesn't have Mandates for this, not sure if this deserves an LWG.

Speaking for only myself, I'm more likely to submit an LWG issue to remove the requirement elsewhere than to submit an issue to add it to basic_string.