Lady, EVOLVED 
thinking of redesigning my website; got distracted by people possibly misunderstanding and at least being really awkward about unicode
“people” in this case being C·S·S·W·G
the current definition of `font-variant-emoji´ simply implicitly adds a V·S·15 or V·S·16 after emoji characters which can take them. this is definitely the least useful possible interpretation of `font-variant-emoji´. if i `font-variant-emoji: text´, i would like NO emoji characters to be given emoji presentation, not “only emoji characters which were not {already encoded codepoints at time of encoding and thus prone to possible awkward re·presentations in pre·existing encoded texts}”
of COURSE this would mean doing additional work, work which may right now be difficult or even impossible, to do font selection to ensure that only fonts which display emoji characters with text presentation are used, and not fonts which display emoji characters with emoji presentation. this is maybe impossible because i am not sure fonts STILL have a good understanding of what “emoji presentation” means nor operating systems fallback mechanisms for properly selecting the correct font for a given presentation. NEVER·THE·LESS
the distinction between emoji style and text style is like the distinction between upright and italic, the existence of variation selectors for some of the set NOTWITHSTANDING
give me the means to choose at the font level!!
the entire POINT is that whether a character has text or emoji presentation should be a quality of higher‐level markup and not encoded at the character level. variation selectors are a begrudging concession for use in limited scenarios where a plaintext distinction may never·the·less be argued for. but that whole conceptual framework doesn’t WORK when your higher‐level markup is just doing “implicitly insert characters into the text stream and then render as plaintext like normal”