I made another alpha release yesterday with my proper localization files to test whether the problem still persists, and it does. For the "real" release, I had to again use my manually-adjusted localization strings. This issue has made the localization system useless for me.
I'm trying to not get worked up about this or blame anyone personally (hey, I'm a coder, too, and I don't just mean of addons; I know bugs happen), but it's very frustrating. I reported this months ago and haven't had so much as a word of acknowledgement that the issue is being investigated.
Someone might think that this is just how it is now and I should adapt, but "how it is" is a buggy mess. As I've outlined above, the system outputs things I expressly told it not to, it fails to output things it's supposed to, and what it outputs causes errors. Imagine there's a system which gives you apples when you ask for oranges and oranges when you ask for apples. One might try to "compensate" for the problem by asking for oranges when you really want apples, but it doesn't end there: What you get back aren't some nice apples; they're useless rotten apples. My point is, if I use some trick to get, say, subnamespaces only where I want them, those subnamespaces will still have syntax errors.
(Throwing that comma on the end like that... I can't compensate for this. I don't even know in what context that would be useful. It's not like I asked for one format and it outputted the other unexpectedly. It gave me a sort of mix of formats that will never work together.)
At least, I can't compensate without a time-consuming reorganization of many keys and a rewrite of much of my localization code. I'd end up removing those subtables entirely, most likely, which is not only tedious but makes it feel much less organized. Reorganizing something into a version of itself that's less organized is just silly.