Right now, because elem_size(char) == 4, if you use stream<char> you're effectively using UTF-32 which is not great. Now that's also the case for list<char> but everyone uses string instead which is encoded/decoded using string-encoding, which is one of utf8, utf16 or latin1+utf16. Symmetrically, we could add a string-stream and indeed there's currently a bullet in Concurrency.md#TODO to add such a thing.

However, in retrospect, list<char> should've probably been special-cased in the ABI lift/lower rules to use string-encoding so that string is pure sugar for list<char> (and if we ever actually needed UTF-32, it could be a new string-encoding=utf32... but probably not). Once we add an opt-in canonopt for #383, we can piggyback other pending breaking ABI changes (e.g., bumping MAX_FLAT_RESULTS to be greater than 1), so we could actually fix this (or not; it bears discussion in the future). But in the meantime, for the upcoming 0.3.0 release, given that if you use stream<char> you're going to have a bad time and we don't necessarily want to add string-stream, the conservative thing to do seems to be to just reject stream<char> at validation time and then we can figure out what we want later w/o breaking anyone.