You seems to do a lot of progress here. But as a person who one time was struggling with 10+ patches freetype patchset in gentoo linux with a sole purpose of getting decent vector fonts I have some insight on current CJK font rendering affairs.

1. There are no way of getting even decent Hangeul and no need to mention traditional Han characters rendering on dpi =<90 without filtering/post-processing which is ubiquitous on commercial products available (Japanese Xerox productset and its numerous offsprings and ripoffs, software you can see used in Korean big 3 products e.t.c.) but obviously covered with 3 or even more overlapping patents in US as whole process (I.E. the famous adobe patent doesn't specify anything more than "improving the resulting image by means of advanced mathematical processing", without even specifying any mathematical concept behind it). Despite of this most of distros of linux and bsds use various filtering patchsets by default. Why I mention this is because most of advanced features enabled fonts doesn't look even as half as good if used without filtering and vice versa, please see attachment 1 and 2 to see how microhei and ipamona font look with freetype's bundled but disabled by default filtering enable.

2. As a result that Most of distributions of freetype turns on both bundled filtering and bci anyway both fontconfig rules writers and open fonts developers should get it in case when drawing fonts and writing config files for them. This way IPA fonts Mona modification which has some spacing and hinting hacks which makes them a drop in replacement for MS Gothic with quirk-less hinting the same way as Microhei outperforms even latest bundled Microsoft and Apple fonts. So Qianqian and Matsuu please install at least bundled filter enabled fc version and look them again prior to rating fonts.

3. Still there are some work to do like having a way to artificially lower weight for IPA Mona fonts in fc=>2.7, as since the version 2.7 setting weight doesn't work any more for those fonts (bug?), the same for ZenHei fonts which have different weight on different fontconfig versions (same bug?).

4. I propose to have separate config file layout for CJK too but with one file like 65-cjk-common to specify global stuff for CJK specific workarounds, specifying Unifont fallback in the most worst cases and so on and to left 65-jp, 65-ko,65-zh-tw,65-zh-hk e.t.c. files for specifying font family aliases and family preferences only and with 65-noncjk-nonlatin for every another thing till time come for them to move the same way.

5. I also strongly support to have commercial fonts sent to something like 
65-cjk-nonfree.

6. On bitmaps, I think there could be a final solution if there would be a per font aliases to have vector fonts and their embedded bitmaps as a separate entities. This would especially help in cases when embedded bitmaps and set of Besier curve based glyphs are not totally overlapping. And as an argument I would mention that on ultra low dpi devices like those sub 90 dpi panel now flooding low-end sector and 210-240 dpi hi-end found in Sony and other brands on Japanese internal market you have to operate CJK either strictly in bitmaps or strictly vector based fonts for various appliances, and leaving the fun of manually rewriting aliases every time either first or the second is needed to end users doesn't seem to be a humane way. Does anybody supports this solution? As fontconfig had always dealt with "synthetic" things I think it wouldn't be a big deal to implement as simple alias.

As a conclusion: I strongly support Qianqian in his will to kill off things that are just 10 or more years outdated. The whole concept of fc was to make all things working out of the box was it? This works now for European langs, the same should be for CJK and every other script. Why you guys not to schedule a brainstorm in IRC before my move to Canada next month so I could consult? People inside the problem used to hang on ##fonts irc channel on irc.freenode.net, so would I next week so come any time and we would try to get in sync for brainstorm. My timezone is UTC+10 but usually I'm on line during evening/night.

P.S. explanation for non CJK savvy devs:
1. proposed layout is : 65-cjk-global with settings like per font global advance adjuster, spacing, and setting unifont or alikes as global fallback and others are 65-cjk-$LANG, 65-noncjk-nonlatin, 95-cjk-synthetic-$LANG-faces/fonts for making bitmaps as separate entities.
2. IPA Mona font is the same IPA font with more of upstream fixes and hack antiquirks to make IPA fonts running fine within free software ecosystem and for making Japanese users comfortable about what they used to think as normal like spacing.
3. The IPA fonts themselves were built by Japanese government and probably stills to be an etalon of how Japanese font should like in general.
4. There are hkscs fonts built by Hongkong which are generally for printing but gives a good insight in concept behind modern traditional Han font.
5. Thoughts behind the original 65-nonlatin were probably based on fact that none of fonts back then had CJK extensions covered fully and the issue was just to deliver and ensure that extension glyphs are just displayed.