No. I think the implementor of Factor's unicode support originally did that but it turns out to not be useful:
* it blows up memory usage for ASCII and BMP (4 bytes per codepoint versus 1~3)
* this also has impact on CPU caches, lowering the average amount of data you can fit in your cache and work on
* it requires a complete conversion of incoming ascii and utf8 data (which only get more and more common as time goes on) rather than just a validation
* and because Unicode itself is variable-length (combining codepoints) it's not actually helpful when you're trying to properly manipulate unicode data
The only "advantage" of representing strings as codepoint arrays is that you get O(1) access to codepoints which is a terrible idea you should not encourage.
UTF-32 internal encoding makes some manipulations very slightly easier, but not enough to matter in the long run, and it encourages bad habits. If you don't need the O(1) access thing for backwards compatibility reasons, don't bother.