Then, after I had changed things back and forth when working with bug #1351092, suddenly I was able to reproduce the behaviour you describe! Now I fear that the fix of this bug report was a mistake. :(
I suggest that we leave this bug report, and continue talking at bug #1351092. Your comments on the idea there would be much appreciated.
Yeah, this is strange. When I first changed to "Droid Sans Fallback" in 69-language- selector- zh-tw.conf, I got this:
$ LANG=zh_TW.UTF-8 fc-match -s 'sans-serif' | head -n 20 Bold.ttf: "DejaVu Sans" "Bold" Oblique. ttf: "DejaVu Sans" "Oblique" BoldOblique. ttf: "DejaVu Sans" "Bold Oblique" Regular. ttf: "Droid Sans" "Regular" ic-Regular. ttf: "Droid Sans" "Regular" -Regular. ttf: "Droid Sans" "Regular" se.ttf: "Droid Sans" "Regular" ckFull. ttf: "Droid Sans" "Regular" ari-Regular. ttf: "Noto Sans Devanagari" "Regular"
uming.ttc: "AR PL UMing TW" "Light"
uming.ttc: "AR PL UMing HK" "Light"
ukai.ttc: "AR PL UKai TW" "Book"
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSans-
DejaVuSans-
DejaVuSans-
Verdana.ttf: "Verdana" "Normal"
Arial.ttf: "Arial" "Normal"
Waree.ttf: "Waree" "Book"
DroidNaskh-
DroidSansEthiop
DroidSansHebrew
DroidSansJapane
DroidSansFallba
ukai.ttc: "AR PL UKai CN" "Book"
uming.ttc: "AR PL UMing CN" "Light"
NotoSansDevanag
KhmerOS.ttf: "Khmer OS" "Regular"
MuktiNarrow.ttf: "Mukti Narrow" "Regular"
I.e. fontconfig seemed to not understand at all.
Then, after I had changed things back and forth when working with bug #1351092, suddenly I was able to reproduce the behaviour you describe! Now I fear that the fix of this bug report was a mistake. :(
I suggest that we leave this bug report, and continue talking at bug #1351092. Your comments on the idea there would be much appreciated.