This should probably go upstream, but I haven't gotten around to reproducing the problem on a clean build of fontconfig master (as opposed to Gentoo's fontconfig-2.11.93 with an additional patch) yet. I'll report it upstream eventually if nobody beats me to it. When I say "old fontconfig" below I mean 2.11.1-r2. When I say "new fontconfig" I mean 2.11.93 with upstream's 4a6f5efd5f6a468e1872d58e589bcf30ba88e2fd applied. As far as I can tell the underlying fontconfig problem boils down to "create a pattern with pixelsize and dpi set, call FcDefaultSubstitute on it, and it will match a font with a pixel size different from the one specified". This can be demonstrated using fc-match. On old fontconfig: % fc-match Terminus:pixelsize=14:size=10.5;dpi=96 ter-x14n.pcf.gz: "Terminus" "Regular" On new fontconfig, this matches ter-x12n.pcf.gz instead. The application I actually have trouble with is rxvt-unicode-9.21, which uses libXft-2.3.2, run with "urxvt -fn xft:Terminus:pixelsize=14" (or the equivalent X resources set). I'm attaching the output with FC_DEBUG=3 XFT_DEBUG=3 set for both versions of fontconfig, which may aid debugging. Unfortunately I cannot quite tell what is supposed to happen here. I think there were multiple changes: FcDefaultSubstitute previously left "size" unset if pixelsize was already set, but now calculates "size" from pixelsize, dpi and scale factor. And I think FcMatch previously matched based on pixelsize, but now prefers size over pixelsize, but I could easily be wrong about that.
Created attachment 402820 [details] XFT_DEBUG=3 FC_DEBUG=3 urxvt, old fontconfig, gzip compressed gunzip to view (1.8M, larger than bugzilla's file size limit).
Created attachment 402822 [details] XFT_DEBUG=3 FC_DEBUG=3 urxvt, new fontconfig, gzip compressed gunzip to view, to not exceed file size limit.