There isn't a need for specific ordering of keys in the object representation. But I want to be able to write parts of the toml document in different orders (e.g. "hosts" table before "certfile"; or "hosts" table after "certfile") and still have the same effective object.
This is an advantage with sqlite as a config store as well - initial db config file augmented in-memory with secrets, accessible from all major languages, without relying on the vagarities of the filesystem (windows vs Linux tmp mount points) and easy to have multiple switchable configurations depending on environment, test mode (integration tests after deployment etc.) or customer.
The "global" and "section specific" stuff stops being so clear once you need to have subsections. And the "clear visual enforcement" can also lead to forced unreadability, when the ordering forced on you doesn't match the most sensible/readable order for a human reader.
This is repeating the same mistake I see all the lightweight markup formats (Markdown, Org Mode, etc.) do - using implicit terminators for hierarchy nodes. It's a superbly annoying feature of outliner tools (including the one I otherwise love: org mode) that forces you to create extra levels of structure just for the sake of being able to surround subtrees with context.
