Besides, the whole point of wchar_t is to not be variable width. UTF-16 in wchar_t is an abomination that dates back to the industry building APIs that take UCS-2 (which the author really ought to cover) before they realized UCS-2 was too narrow to do its job. So now we have a lot of code that appears to support Unicode but may not handle it correctly, depending on whether QA knew they should try surrogate pairs. Almost nobody realizes UTF-16 needs to be searched and spliced as carefully as UTF-8. Each is just a compression scheme for the million or so actual codepoints, and there aren't many reasons to favor one over the other (in memory, at least).
What's the actual problem here, the team made assumptions that ANSI warned against making? Apple failed to accept UCS-4 for their API?