bug#45620: 28.0.50; Child frames should have their own border width and colour

[Alexander Miller <alexanderm@web.de>]

 > Isn't the situation even worse than how you describe it here? When I
 > customize 'internal-border' face, that affects all frames, including
 > those for which I have set it already via 'set-face-background'. Which
 > means that whatever a package does to set that face for a specific
 > (child) frame, that setting is undone by a later customization. IIUC
 > the discussion you refer to above arrived at the same conclusion.

What customisations are you referring to? I cannot think of any
scenario, other than changing and reloading your theme, that could
change the settings of already present child frames.

 > If I'm not mistaken we use that face for our tooltip frames too which
 > means one more conflict.

Partially. On my system the internal-border colour and width only
applied to the top and left sides of the tooltip frame.

 > "clearly" is clearly too strong here. Ultimately, the package must have
 > the choice and its choice should prevail (it currently doesn't).

Packages do have the choice, they just have to make sure to override the
frame-local faces whenever they show something. The problem, as I see
it, is that they *have to* create a face to override the local
internal-border, instead of just having the option to do it, because
themes cannot offer a general setting, like an easily visible dark
border on a bright foreground, because they run into the frame margin
colour conflict like modus did in the linked issue. So if a package
doesn't overwrite the local internal-border your default look-and-feel
is a badly visible same-colour-on-same-colour popup.

 > So what should we do? Provide a separate 'child-frame-internal-border'
 > face and then probably also a 'tooltip-internal-border-face'?

That would be perfectly good enough for themes like modus, yes.