> This is not an Emoji character, this is NBSP.

Upps, my bad, obviously, seems that `(emoji-list)' skips those unrenderable emoji.
For describe-char on "😊", I get

--8<---------------cut here---------------start------------->8---
                position: 523 of 1964 (27%), restriction: <103-1965>, column: 0
                character: 😊 (displayed as 😊) (codepoint 128522, #o373012, #x1f60a)
                charset: unicode (Unicode (ISO10646))
    code point in charset: 0x1F60A
                script: emoji
                syntax: w 	which means: word
                category: .:Base
                to input: type "C-x 8 RET 1f60a" or "C-x 8 RET SMILING FACE WITH SMILING EYES"
            buffer code: #xF0 #x9F #x98 #x8A
                file code: #xF0 #x9F #x98 #x8A (encoded by coding system utf-8-unix)
                display: no font available

    Character code properties: customize what to show
    name: SMILING FACE WITH SMILING EYES
    general-category: So (Symbol, Other)
    decomposition: (128522) ('😊')

    There are text properties here:
    fontified            t
    wrap-prefix          ""
    ws-butler-chg        chg
--8<---------------cut here---------------end--------------->8---

I now also attached some screenshots of the emoji-list and also of the completion-buffer when I press <tab> in emoji-search, which shows the unicode placeholders that I get, so it might be more clear what my problem is.

> Do you have Color Note Emoji font installed?

 "Noto Color Emoji" is in the output of '(font-family-list) ` and it's also installed via my system package manager. Weirdly, if try to change the frame font to "Noto Color Emoji", which I did via the menu-bar "options->set default font", I get the error message

    set-frame-font: Font not available: #<font-spec nil nil Noto\ Color\ Emoji nil nil normal normal nil 10.0 nil nil nil nil>

I get this for all other emoji fonts that I have installed, but maybe this is normal for an emoji font because setting it as font for the entire frame doesn't make much sense, but I don't know if this is not a hint of an underlying font-config issue.

> Could this be bug#57066?  Does the patch posted there fix the problem?

I agree this is likely to be an issue with harfbuzz, even though the symptoms of this bug look different from bug#57066, as I just don't get any rendered emoji instead of overlapping emoji (see attached screenshots). I will try this patch anyway after this mail.

I also saw bug#56789 which seemed similar in symptoms, but I just checked that my archlinux installation has harfbuzz 5.1.0, where the bug causing #56789 is should be fixed as far as I understood. I tried a clean rebuild to make sure I use that harfbuzz version and also I tried downgrading harfbuzz to 4.4.1 and rebuilding emacs and neither solved my rendering issues. I also tried the command

    hb-view  --output-file=foo.svg --font-size=13 \
    /usr/share/fonts/noto/NotoColorEmoji.ttf \
    -u 1f469,200d,2764,fe0f,200d,1f468

and it works, producing a nice SVG emoji image. So it's not that harfbuzz in general is broken.

Thanks for the help,
Michael