It took me a while to get my default fonts working again but I think I'm starting to have the slightest hint of an idea how fontconfig works .  The core issue that affected me seems to be that some fonts define their generic family but others don't (at least I assume so, they end up with 0 as the value, see man fonts.conf for the list of constant names and values) and the generic family is higher in the match priority than the default "weak" binding of the family when setting preferred fonts via the methods the arch wiki documents.  This means a random font that does have the generic family correctly set gets picked instead of what I wanted.

There are two basic ways to fix this:

1. The correct way: add correct genericfamily settings for each font without it (it sounds like fontconfig is planning to do this for fonts mentioned in their config files so just waiting a bit should help):

   <fontconfig>
     <match target="scan">
       <test name="family"><string>Font Name</string></test>
       <edit name="genericfamily" mode="assign_replace" binding="same">
         <const>genericfamily</const>
       </edit>
     </match>
   </fontconfig>

   Of course replace Font Name with the family name of your font and the genericfamily inside the const tags with one of the generic names from man fonts.conf (use multiple const sections if you want it to have multiple generic families).  You can use

   fc-list ':' family genericfamily | grep 'genericfamily=0'

   to get a list of fonts that don't have the genericfamily set.  Run fc-cache -r as root and each user after changing this configuration (also I found some stale cache data in /var/cache/fontconfig even after fc-cache -r so maybe first rm -rf /var/cache/fontconfig and each user's ~/.cache/fontconfig, though I didn't see any sign it is used).

2. Use strong bindings to set family preferences, with binding="strong" on either the alias or edit tags.  However, a disadvantage of doing this is that the strong family binding has higher priority than both the language and a postscript name provided by the application so it seems like this would produce worse results unless you do more complex matching before setting the high priority family binding.  It sounds like the strong binding is intended to apply to what the application requests.

I've spent way to much time on fontconfig without having even a basic idea how it works so hopefully this summary will help someone.  There are three basic stages corresponding to the three possible values of the target property of the match tag.  First, target="scan" is what fc-cache does and it builds a database describing each available font.  This is where rejectfont and acceptfont are applied and is why target="scan" is needed to set the genericfamily property of a font and why fc-cache -r is needed (well, the -r is needed because the cache doesn't seem to get invalidated if the config changes).  The second stage is target="pattern", the default target of match tags.  The application provides details about what it cares about to fontconfig and configuration can modify that information before it is used to lookup fonts from the cache based on the priority order linked above.  Once fonts are selected the third target="font" stage is run where font features can be altered and some other settings like hinting and subpixel rendering (any settings that affects rendering rather than lookup).