Quoting user “Gee” in the Discord
unicode(dot)org/Public/emoji/14.0/emoji-test.txt According to this, FE0F should be preserved to be “fully qualified”.
Current implementations SEEM to be as follows: - Obviously, the contract takes anything you send it. - Etherscan and OpenSea will not strip FE0F when resolving/displaying! (But OpenSea for some reason DOES parse it down in SOME contexts, leading to keycap emojis being listed as length 2) - MetaMask and ens.domains does not preserve it.
It comes out filtered when you register with the frontend, so the registration would actually map to the parsed down “unqualified” version in the contract. This also causes it to look garbled when displayed back on some frontends, including ens.domains itself.
There are many emojis with the variation selector 16 modifier (CTRL+F in that doc shows 1079). I don’t know yet under what other contexts the modifier is stripped.
tl;dr
metamask/ens filter on lookup and ens registers the parsed out version thus saves that one to contract. (resolves stripped) opensea/etherscan don’t parse out or filter on lookup. any affected domains would have to be looked up with the character filtered out on these platforms. (resolves raw) also, I wonder if any of these or similar issues could be platform dependent - could metamask or browser dapps be filtering/displaying differently based on platform? unfamiliar with this area. It seems ENS should make it clearer how the implementation should be.
More specifically
This is the URL for the OG genie 
using Joiners ENS App
This is the URL for the Male Genie 🧞‍♂️ using Joiners and FE0F ENS App
But when you visit the second URL (Male Genie), it shows the same record as the first URL (OG Genie) even though they are 2 different emojis and they are hosted in 2 different wallets
Then, you can view the address page for the first one: app.ens.domains/address/0xFB0FBfB5EC04d6C1c96a27d755dD2DB221C9a20A
But if you try to view the address page for the second one, it crashes: app.ens.domains/address/0x147ca0da3a1ecef2c1892d518266c9f3279bb8bc
that address at app.ens.domains/address/0x147ca0da3a1ecef2c1892d518266c9f3279bb8bc owns the emoji with the FE0F, but when the page attempts to load the list of owned names it probably gets confused because at some point the FE0F gets stripped, so now it’s listing an ENS name that’s actually owned by a different address