> I'm not really a fan of the new "would_cast_modify". It doesn't feel standardese enough. "Modify" has a strong connotation of memory modification, but you never modify x in a [defns.access] sense when casting. The C++ standard doesn't use this kind of wording for loss of precision.
>I would name it "is_representable_as" or "representable_as".

I can change the name to something else, but I think we should get to a consensus as to what it should be before editing the paper any further.

> Perhaps you could scale this idea down to a type trait std::is_representable_as_v<T, Dest> and a concept std::representable_as<T, Dest>

This goes against the original point of why the function should exist, the construction of std::is_representable_as_v<T, Dest> would require it to be a compile time constant expression that doesn't consider the actual value encoded in the type.
Take for example int8_t with the value of -1, and I try to cast it to an uint32_t, you will be able to copy all the bits over, the process may even be round-trip convertible, but uint32_t cannot represent -1.
Conversely an int32_t loaded with the value -56 can be casted to an int8_t and it would still represent -56 even tough it would drop bits.
Now you may be in a situation where you don't know the value that you are going to have until the application is running and the problem presents itself at runtime.
The check isn't about just being narrowing, but more of "can I represent this specific number as this other type?".