Thanks for your detailed feedback.

>> I don't understand your question.  If we agree that there is an order 
>> of importance in the attributes of a font spec, and that the family is 
>> the most important one, it seems clear to me that keeping the family is 
>> more important than keeping the weight.  What am I missing?
>
> The order on which we agreed is only about the numerical attributes: 
> width, height, weight, and slant.  I'm asking about the other 
> attributes, and about their importance relative to the numerical ones. 
> You seem to say that this order is self-evident, and I'm questioning 
> that.
>

Okay, now I see what you mean.  It is not self-evident indeed, it is the 
intended behavior that is visible (or at least that I see) in the existing 
code, and it seems to me that it is the most natural behavior, because 
changing the font itself, e.g. from DejaVu to Courier, has more effect / 
creates more visual diversity than only changing the 
width/height/weight/slant attributes, and in graphical user interfaces 
more uniformity is better than more diversity.

>> I checked in particular it with the recipes of bug#37473, bug#57555, 
>> bug#59347 and bug#59371, and with some variants.  All seem to work 
>> correctly.
>
> What about bug#51768, bug#52493, bug#52888, and the problem reported in 
> https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg01643.html?
>

bug#51768: Works as expected here, with '(default ((t (:family "Source 
Code Pro" :foundry "outline" :slant normal :weight medium :height 90 
:width normal)))).

bug#52493: Works as expected here, the Inconsolata_dz font is used and 
rendered correctly.  But the original recipe doesn't work anymore (it does 
not work in Emacs 28 either), it should be :font "Inconsolata_dz" instead 
of :family "Inconsolata_dz".

bug#52888: That bug seems unrelated to the current bug, but I see no 
difference in behavior between Emacs 28 and Emacs 29 with the patch.

problem reported on emacs-devel: The medium weight is selected both for 
frames that are created by calling emacs and for frames that are created 
by calling emacsclient.

>
> Also, did you test Emacs invocation as in "emacs -fn FONT" where FONT is 
> specified as Fontconfig and XLFD patterns documented in the "Fonts" node 
> of the Emacs user manual?  E.g., what happens if you use the Fontconfig 
> pattern such as "Sans 
> Serif-12:weight=black:slant=oblique:width=condensed"? -- does Emacs 
> start with a font with the expected attributes, both when such a font 
> which matches exactly exists and when an exact match doesn't exist?
>

emacs -Q -fn 'Sans Serif-12:slant=oblique:width=condensed'

works as expected and behaves like Emacs 28: the font for the default face 
is a condensed and oblique variable-pitch sans serif font.

emacs-28 -Q -fn 'Sans Serif-12:weight=black:slant=oblique:width=condensed'

displays the same error in Emacs 28, 29, and 29 with the patch:

Font 'Sans Serif-12:weight=black:slant=oblique:width=condensed' is not 
defined

>
> As I mentioned earlier, any such change must be controlled by a variable 
> exposed to Lisp, which could then be used to investigate and perhaps 
> countermand any regressions it could cause.  If you agree to adding such 
> a variable, I'm okay with installing this on the emacs-29 branch.
>

Okay, so here is an updated patch.  To make it easier to investigate bugs 
in this area, I think it makes sense to control each field separately, and 
also to allow unsetting other attributes, which is what the new variable 
does.