bug#53636: 29.0.50; face-remapping broken on master

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 53636@debbugs.gnu.org,  tsdh@gnu.org
> Date: Tue, 08 Feb 2022 07:08:29 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > And what happens when you call make-frame from another buffer is not a
> > bug?  Is face-remapping-alist supposed to affect the buffer in which
> > it is set on all frames or just on the single frame where
> > face-remap-add-relative was called?
> 
> I'm not sure.  But the current behaviour (affecting all buffers on the
> new frame) has to be a bug.
> 
> >> The computation of the faces for the new frame.
> >
> > You mean init_frame_faces, which calls realize_basic_faces?  Or do you
> > mean some other kind of "face computation"?
> 
> I don't know?  I'm looking for the code that leads to the behaviour I
> described.

We need to agree on what "this behavior" is.  Or at least I need to
understand what you mean by that, in order to be able to provide
information that could help you.

So: in the scenario you've shown, do we want *scratch* to have its
mode-line remapped on the new frame, or don't we?  IOW, I agree that
the result ideally shouldn't depend on the buffer where make-frame is
called, but I need to know what is the desired behavior in order to
find code which produces the undesired results.