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". This has
a lot of precedent; for example, a narrowing conversion is valid if
the target type can "represent all the values of the original type".
You could also call it "is_narrowing", but that would be misleading
because a function template cannot test for narrowing conversion.

This also begs the question: Instead of "would_cast_modify<T>(x)" one
can write "requires { T{x}; }" to test for narrowing. This expression
would also be true if some values of x are not representable as T, but
x is a constant who happens to fit into T anyway. Isn't this a
sufficient replacement and a superior alternative to the proposed
function? Your function loses any information about x being usable in
a constant expression. Inside of would_cast_modify, the function
parameter is never a constant expression. 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>. The user can do "requires {
T{x}; }" when they have a specific x.

On an editorial note, I recommend using a consistent style and
formatting for inline code. You use "mul_wide" something like 60% of
the time and mul_wide 40% of the time. Personally, I would use a
fixed-width font for all inline code and possibly give it a bit of a
gray background color, similar to inline code on GitHub in Markdown.

In the motivation, CPU's should be CPUs. "In other application" should
be "In other applications". There should presumably be an "and"
between "cumbersome" and "error prone".