>> In this case, ISTM that the problem is not the font, but the shaping 
>> engine.  If Harfbuzz does not know how handle the joiners and segment 
>> delimiters, it should behave as they did not exist, and use the font 
>> ligatures (if the font does have ligatures)
>
> AFAICT, this is what happens here.
>

No, because Harfbuzz displays the fictitious joiner and deelimiter glyphs, 
and does not try to use the ligatures that the font provides.

>> instead of displaying the fictitious glyph at that codepoint (at the 
>> codepoint of the joiner or delimiter).
>
> I don't think I understand what fictitious glyph you allude to here. The 
> joiners were displayed as thin spaces by the Emacs 
> glyphless-char-display feature, because HarfBuzz+font didn't compose the 
> sequence, and returned the separate font glyphs for each codepoint in 
> the sequence.  IOW, the composition failed, and therefore Emacs 
> displayed each of these characters as it's supposed to do.
>

A picture is worth a thousand words.  I attach four files:

In 1.png you see what Harfbuzz displays with the previous HELLO entry. 
The three glyphs with a thick rectangle above and a crossed rectangle 
below are a fictitious glyph in the Aegyptus font for the codepoint 
hieroglyph vertical joiner, and the opening and closing parentheses are 
fictitious glyphs in the Aegyptus font for the codepoints hieroglyph begin 
and end segment.

In 2.png you see what I would expect Harfbuzz to do with the previous 
HELLO entry, if it knows that it cannot handle the joiner and segment 
delimiters or if it detects that the font does not provide enough 
information to handle them appropriately, and if the font has no 
ligatures: displaying the hieroglyphs one after the other.  That's what I 
would expect to see with the Noto Hieroglyph font for example.

In 3.png you see what I would expect Harfbuzz to do with the previous 
HELLO entry, if it knows that it cannot handle the joiner and segment 
delimiters or if it detects that the font does not provide enough 
information to handle them appropriately, and if the font does have 
ligatures: displaying the hieroglyphs with the ligatures provided by the 
font.  That's what I would expect to see with the Aegyptus font.

In 4.png you see what I would expect Harfbuzz to do with the previous 
HELLO entry, if it knows that it can handle the joiner and segment 
delimiters and if it detects that the font does provide enough information 
to handle them appropriately.

>>> I mean what the Unicode Standard says: it says that two hieroglyphs 
>>> should be displayed "normally", i.e. as separate characters at the 
>>> same vertical position, unless there's the vertical joiner between 
>>> them, in which case one should be above the other.
>>
>> I understand.  But what the standard says doesn't make sense I think, 
>> because it means that it requires one to ignore font ligatures and 
>> instead requires one to use joiners and segment delimiters.
>
> No, the joiners are supposed to tell the shaping engine and the font 
> that we want the ligatures and not separate font glyphs.
>

Unless I misunderstand something, a text without joiners and delimiters 
would thus be displayed as 2.png, even if the underlying font provides 
ligatures with which it could be displayed as 3.png.  And ZWNJ would be 
ignored.  Which makes, as I said, the task of those who want to edit 
egyptian texts much harder, and unnecessarily so.

>> Here's a combined patch, with the comment you asked.
>
> Thanks, installed on the release branch.
>

Thanks!