Wrong added_in version for "handshake" variations with a single skin tone.

[jwheare]

These are listed as 3.0, but 3.0 didn't have skin toned handshakes. The multi skin tone versions are correctly listed as 14.0.

This prevents correct browser support detection in our fork of the js lib.

[jwheare]

This actually looks like a bug in the unicode source files, they versioned as 3.0 here too.
https://www.unicode.org/Public/emoji/14.0/emoji-sequences.txt

This looks like it crept in for a lot of other emoji since version 13 of those files. e.g.

index pointing up: light skin tone                             # E1.0

v12 looks more correct:
https://www.unicode.org/Public/emoji/12.0/emoji-sequences.txt

index pointing up: light skin tone                             #  8.0

I think this is only manifesting as an issue now because it's hitting brand new versions of quite old emojis. The other emojis this affects have old enough skin tones that our lib is already treating them as universally supported.

[emoji0]

Handshakes with skin tones are listed in version 3.0.

[emoji0]

This looks like it crept in for a lot of other emoji since version 13 of those files.

Since version 13.0 the Emoji Charts version is displayed (hence the E prefix), before that the Unicode version was specified.

[jwheare]

Looks like they were never included in the RGI (Recommended for General Interchange) list until 14.0. They're listed as being introduced in 14.0 here https://emojipedia.org/emoji-14.0/

Some more info here https://www.unicode.org/reports/tr51/tr51-21.html#multiperson_skintones

[emoji0]

Looks like they were never included in the RGI (Recommended for General Interchange) list until 14.0. They're listed as being introduced in 14.0 here https://emojipedia.org/emoji-14.0/

It's almost correct. The sequences for handshakes has been deprecated since version 4.0 (but there where listed in 3.0), but returned in version 14.0

[jwheare]

OK, that's kind of awkward. I'd say the data should reflect the most recent version for cases like this. Might need to be special cased in the build if that info isn't available from any unicode.org source files.

[emoji0]

Pay attention to this:

As of version 13.0, data file comments use the labeling convention “Ex.x”. This label corresponds to the Emoji version when the emoji character or emoji sequence was first defined in associated data files.

[jwheare]

I understand, but that's not helpful in this case for anyone trying to determine compatibility of native emoji rendering while supporting a range of different OS versions.