See also the item starting with "The FP constructor is a bit a mess..." at #10249, I guess.
Based on the writeup at #10249 I vaguely suspect we should rather deprecate FP(family) because that's easily written as FP(family=family) (consistently with all other attributes), and if anything the constructor without named parameter should take a pattern (... perhaps a CSS pattern, but that's another issue).

Sure. We could do __init__(pattern=None, /, *, family=None, ...). Notes:

• We still need an either pattern or the other parameters internal check, i.e. we have two orthogonal APIs in the constructor, but at least they are logically separated.
• for the deprecation: can we detect whether a given single parameter is a family rather than a pattern?

• for the deprecation: can we detect whether a given single parameter is a family rather than a pattern?

In the single-arg case, I would try calling parse_fontconfig_pattern, then if it raises, treat as a family (and warn) (If it doesn't raise, this can also occur if the family and the pattern are identical, e.g. "Times" parses as {"family": "Times"}.)

Superseeded by #28843.