I think I agree that using the char32_t type as the Unicode scalar value
type that is the lingua franca for Unicode algorithms makes sense. The
advantages of a `scalar_value` would be a place to hang the contract off
of, to possibly provide a checked mode, and to signal that validation has
been done.

But, it would probably just encourage people to write a range cast, like
views::transform([](char32_t c){return scalar_value{c};}) which would help
no one.

Writing a validation view for scalar values is fairly trivial.

Unicode algorithms, however, must not over trust their input then. We
should not have UB in the std library. So that implies that any property
lookups for int32 s that aren't scalar values have to say NO and the
algorithms should handle that. Many do naturally. But we should not repeat
the mistakes of the original C character classification APIs.