>> +(defun char-graphically-displayable-p (char &optional frame)
>
> I prefer char-displayable-on-frame-p (since "graphically might be
> interpreted as meaning only GUI frames).
>
>> +  "Return non-nil if CHAR can be graphically displayed in FRAME.
>> +FRAME nil or omitted means use the selected frame.
>> +
>> +This function provides a more reliable test than `char-displayable-p'
>> +for determining if a character will display properly.
>
> "More reliable" will cause people wonder why we have "unreliable"
> APIs.  But the essence is not the reliability, the essence is
> accuracy: char-displayable-p returns the ability of the entire Emacs
> session, whereas this new function returns the ability of a particular
> frame.
>
> I also think this function should be documented in the ELisp manual
> and in NEWS, but that could be a separate patch.

Thanks for pushing for clarity on this.

One thing I realized is that the implementation I had given of the new
function was incorrect in its handling of the frame argument, because
the function char-displayable-p does seem to depend upon the selected
frame (e.g., on a graphical terminal with multiple frames, each having
their own default face or font-backend).

Assuming I haven't misunderstood, I saw a few options for correcting the
new function:

1. Wrap char-displayable-p in (with-selected-frame ...).

2. Give char-displayable-p a frame argument, and wrap its body in
   (with-selected-frame ...).

3. Drop the frame argument altogether (leaving (with-selected-frame
   ...) to callers of these functions).

Option (3) seemed simplest to me, and also at the least risk of
introducing confusion concerning the name of the new function: at a
glance, "char-displayable-on-frame-p" might suggest incorrectly that it
does the analogue for the given frame of what char-displayable-p does
for the selected frame.  I went with (3) for now, but would be happy to
adjust if desired.  Please see attached.