utf16 is not a windows-ism. It is the encoding of strings in the DOM and JavaScript. That you think it is a windows-ism indicates a lack of familiarity with the

utf16 is not a windows-ism. It is the encoding of strings in the DOM and JavaScript. That you think it is a windows-ism indicates a lack of familiarity with the web. More specifically, JS is UCS-2 rather than utf16 so strings can also validly contain unmatched surrogates. If WASM is expected to being compatible with the web - which I would have thought was a given, given that browsers are the primary execution engines for wasm, and the V8 javascript engine seems to be the primary non-web wasm runtime - then WASM has to accept UCS-2 strings. I don't deny that the post seems biased over specific features, but I want to be super clear that the string issue specifically is not a windows-ism and is a critical element of the primary WASM host environments.