On the second poll, I'll copy the message I sent before the meeting
There are further issues here.
The width of grapheme is independent of encodings.
We are just not forcing implementation not to decode. Is that what we want?
I don't think it is useful.
Most encodings cannot represent any of the wide codepoints, the wideness of codepoints in shift jis can be derived without doing a full decoding.
For a string decoded to a sequence of unicode codepoints, its width is the sum of estimated widths of the first code points in its extended grapheme clusters.
If the intent is for implementers to throw their hands in the air when the encoding is not "a unicode encoding", then surely
we want to support UTF-8/16/32 and that's it. UTF-EBCDIC isn't more important or special than shift-jis and there is no reason for one encoding to have privileged handling over the other.
More generally, any unicode that can round trip through Unicode should qualify as Unicode encoding, but I don't think we have a definition of that anywhere.
Unicode defines Unicode Encoding Form
> A character encoding form that assigns each Unicode scalar value to a unique code unit sequence
Ie, I don't think the poll solves anything, it just uses a different terminology to describe the same thing (nothing in iso 10646 leads me to believe that "ucs encoding scheme" can only designate ucs encoding forms specified in iso 10646 - in addition of being obscure terminology).
On GB18030, it's a different character set, with its own set of encodings