In the case of “keycap” characters, is the “normalized” version actually invalid?
For example there is a “Digit Six” emoji: 
This is constructed with 6 and U+FE0F, so I would assume this would abide by all the same rules enumerated here. I guess technically is the “fully-qualified” version of 6.
But then, there is a completely separate “Keycap Digit Six” emoji:
This one is constructed with the Digit Six emoji above, plus the U+20E3 “Combining Enclosing Keycap” character. So the full sequence for is 6 + U+FE0F + U+20E3.
When this normalization process is applied to the Keycap Digit Six emoji, the FE0F is stripped out from the middle of the sequence, not the end. So now what you’re left with is 6 + U+20E3. Is this a valid sequence at this point?
For example, if you have the following HTML:
<p>6⃣</p>
<p>6️⃣</p>
The first one will not render as , only the second one.
And this matches up with what the manager UI currently shows:
Ultimately it doesn’t change the fact that as long as everyone follows the same normalization rules, it shouldn’t break resolution. If you enter 
.eth and registered via the ENS manager app, you will actually register 6⃣9⃣.eth. And then if you enter .eth in Metamask, you will actually be sending to 6⃣9⃣.eth. Okay, all is well I suppose.
But I guess the nuance here is that in order to abide by these normalization rules, you just need to come to terms with the (apparent) fact that the domain you registered is not actually the real Keycap Digit Sequence. And if you do manually register the correct full sequence against the smart contract, sorry, but the ENS community has decided by social contract (by using the same normalization rules) that your domain will never actually be resolved to from the actual Keycap characters.
So, I guess that sucks for anyone who manually registered .eth (or any other name with a keycap sequence) against the contract and someone else owns 6⃣9⃣.eth, because the full and correct sequence will effectively be useless in web3 client sites/dapps.
However like Nick and others have stated, if we change the normalization rules, now it could effectively screw over anyone holding 6⃣9⃣.eth because now .eth would no longer resolve to their domain whereas previously it would. And someone else paying attention to these threads could then come in and snipe that full correct version before the original owner (who thought they registered .eth) is aware anything changed.
FYI for the above, it looks like these forums automatically convert those keycap emojis, here’s what I see in the edit pane before saving just for reference, you can see the difference between the regular Digit Six and the Keycap Digit Six emojis:
”) produces output which is not equivalent to the input, and invalid unicode. This is an important distinction for 2 reasons:
(<-- hope this renders ok)
” 0x1F9B8 0x200D 0x2640 0xFE0F, which reads “superhero + (woman in emoji form)”. The woman symbol 0x2640 can be expressed in non-emoji form (
), but as part of an emoji sequence, the “emoji” variation is required for proper display.
