>> I guess, but do we really want our users to shove random integers in it
>>
>
> Yes. I really want a wide contract there

But... why?

>> Yes, contract or invariant means strong type, not dumb char32_t
>>
>
> TR 44 is purposefully dumb by design too.

I guess it was written by people with more of a C mindset. I'm looking
at std::chrono and love how I can never shove an integer there because
it is ambiguous. Same with text - an integer is ambiguous without
character set or encoding. I know this api has Unicode in its name
but... I think I gotta try to come up with properties design that is
compatible with my design and see if there are any bad points.

Also, I know this is a bit obscure, but what about non-Unicode? I think
having relatively universal free functions is fine and then if they get
std::unicode_code_point as template parameter, they will select unicode
implementation. Hence again, strong types are important.

Also, consider std::ascii_character, std::shift_jis_something.. I don't
know Shift-JIS. :/