The way we ended up designing the LangStrings system was to not create the files using Python. I think this is probably the best way to do it, and I actually was never really big on what cfglib.AddonINI ended up becoming. I need to add this to the thread about LangStrings, but we ended up going with a 2 file system, which is what I originally proposed for inilib (which became cfglib.AddonINI) for ES. The basic idea is that you pass LangStrings your ini file's location, and then it automatically creates a server specific file that the server operator can use to add/modify language strings to. The reason for the server specific file is so that when an addon gets updated, it should only contain the original ini, and not the server specific one, so that only the original gets overwritten. And yes, I do notice the need for other .ini files, as well, that scripters will need (especially when it comes to the dyncall and dyndetours functionality).
*Edit: went ahead and removed that comment from ini's in list above