There are incorrect glyphs in my locale!

^{N.B. I am a newcomer to GlyphWiki myself, so the observations below may not be entirely correct, and there may be exceptions to the rule given the nature of collaborative editing. I've created an issue here for further discussion and observations on locale-specific needs.}

In GlyphWiki, default names (e.g. u7940) are usually aliased to the J-source variant or even the -jv variant if one exists; thus u7940 is aliased to u7940-j, and u6eb8 is aliased to u6eb8-jv as of the time of writing, otherwise it is aliased to the primary locale from which it originates.

For instance, 纷, being the Simplified Chinese-exclusive variant of 紛, necessarily only has a G-source glyph. u7eb7 is thus an alias of u7eb7-g. Note the absence of the brief horizontal stroke in 八 compared to 八, as well as the lack of discontinuity in 纟 vs 糸, which are characteristics of modern G-source 宋体, which in turn takes on many features of regular script.

𫙹(ブリザード) is a recently-coined, 和製漢字 with no G-source, even though in theory a G-styled glyph with 山 instead of 山 could be created (note the boxy protrusion to the bottom left, once again a 新字形 artifact).

払, the 新字体 of 拂, is a variant attested to in the 康熙字典, hence, naturally it has a G-variant too, 払.

Yet still, there exist Korean-only 國字 which made their way into the PRC's GB standards, e.g. 乻 with the first stroke in 乻 rendered as a 丶 instead.

In the absence of a locale-specific glyph, the default name is used. When generating the SC font, the (sole) J-variant is used for 𫙹, which makes sense to me since it almost always appears in a Japanese context. The same would apply to non-SC fonts using 纷.

Unfortunately, currently, locale-specific glyphs for the URO are far from complete. Using 諞 as an example; as of April 9, 2021 only its G and J-source glyphs are defined. Therefore, in the TC font, u8ade uses the u8ade-j glyph by default. When invoking the locl feature using the TC font, all locales except zh-Hans fall back to the u8ade-j glyph. zh-Hans works properly because there would be a substitution rule which replaces whatever CID u8ade points to with u8ade-g unconditionally, which exists.

It is unclear whether, say, u8ade && locl=vi (nonexistent) -> u8ade (nonexistent) -> u8ade-j is a desirable fallback strategy. For one, various Nôm-targeted fonts are based on Song-style glyphs, not least the eponymous 喃 (nôm)那(na)宋(tống) Light font, which is a V-source Unicode code chart reference font, as well as the Han Nom fonts, used in the 字Từ典Điển𡨸Chữ喃 Nôm摘 Trích引 Dẫn, hence fallback to any of G, T, or even H sources could be desirable.

Simply leaving those glyphs unpopulated, thus allowing the user to choose a suitable font stack, is another possibility, although the locl feature for that codepoint would no longer work because there is no glyph to substitute for anymore!

Charts showing which locale-specific glyphs are available in the URO and whether they have been added to GlyphWiki are available here.

Gothic font is missing lots of strokes!

Yes, that's probably why kage.kShotai = kage.kGothic isn't documented yet. I'm keeping track of the gothic related issues I've found here.

Is there any reasoning behind the A, B, C, and D splits?

In the CJK fonts, as many of the East Asian-related Unicode blocks are added to the A file as possible to pass fc-validate so that there are less catches with fontconfig when trying to prioritize it over system fonts. Simply avoid installing the D split if you don't want to use non East Asian glyphs.

$ fc-validate -l zh_cn HanaMinLiteCJKATC.otf
HanaMinLiteCJKATC.otf:0 Satisfy the coverage for zh-cn language
$ fc-validate -l zh_tw HanaMinLiteCJKATC.otf
HanaMinLiteCJKATC.otf:0 Satisfy the coverage for zh-tw language
$ fc-validate -l zh_hk HanaMinLiteCJKATC.otf
HanaMinLiteCJKATC.otf:0 Missing 121 glyph(s) to satisfy the coverage for zh-hk language
$ fc-validate -l ja_jp HanaMinLiteCJKATC.otf
HanaMinLiteCJKATC.otf:0 Satisfy the coverage for ja language
$ fc-validate -l ko_kr HanaMinLiteCJKATC.otf
HanaMinLiteCJKATC.otf:0 Satisfy the coverage for ko language