These all have Emoji_Presentation=No as specified in emoji-data.txt, for precisely this reason (to avoid discrepancies in rendering), but most platforms don't respect these defaults, as it's common to get strings containing emoji from mobile devices, which usually default to emoji presentation. I talk about this a little in my recent "Text layout is a loose hierarchy of segmentation" blog post.
My recollection is for the textual characters that got repurposed as emoji, it’s implementation-defined as to whether the character defaults to text or emoji but that most renderers opt for emoji (which I believe is copying Apple’s decision here). There are variation selectors you can use to force textual or emoji presentation.
That file is new in Unicode 13. Also I think it might be based on Apple's behavior. I just tested every single emoji codepoint listed there, and it's almost entirely consistent with Apple's default rendering. And the very few exceptions (like ) actually seem to depend on whether the text renderer is styled or not, where it becomes emoji in styled fields (like Spotlight) and text in plain-text fields (like this comment box). This seems to only be done for the small handful of pre-existing text symbols that got turned into emoji and given the Emoji_Presentation property.
