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

[Eli Zaretskii]

> Date: Tue, 8 Feb 2022 09:58:31 +0100
> Cc: 53636@debbugs.gnu.org, tsdh@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  >> 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.
> 
> Face remapping has never been properly synchronized with windows and
> frames.  What's needed is a simple hierarchy window > window's buffer >
> window's frame where the first should be implemented with the help of a
> 'face-remapping' window parameter and the last with the help of a
> 'face-remapping' frame parameter.  Just like we (should) do for things
> like the scroll bars or fringes.  But we need a consensus on this first.

I don't think I understand this remark.  While what you describe might
be a useful addition, I don't see why we must have it, or else.
Surely, Emacs has gobs of features that depend only on the buffer, but
not on the window nor the frame where that buffer is displayed?  Why
cannot we have a reasonable behavior with face-remapping-alist being
specific to a buffer, no matter in what window we display it?