Why INI has no single official specification

Unlike JSON or YAML, the INI format was never formally standardized — it emerged from early Windows configuration files and then got independently reimplemented by countless tools and languages, each adding its own small variations: some accept `key: value` alongside `key=value`, some support dotted subsections, some allow duplicate keys to accumulate into an array rather than overwriting, and comment characters vary between `;` and `#` depending on the tool. This tool implements the common core that essentially every INI dialect agrees on — sections, key/value pairs, both comment styles, quoted values — deliberately staying permissive rather than picking one specific program's dialect as the "correct" one, since there genuinely isn't a canonical INI standard to be correct against.

Why keys before any section header get a "(root)" home

Plenty of real INI files have a handful of settings at the very top before the first `[section]` header appears — global options that apply outside any specific section's scope. Since every parsed key in this tool's output needs to belong to some section for the data structure to stay consistent, those pre-header keys get grouped under a synthetic "(root)" section rather than being dropped or causing a parse error. That keeps the tool's JSON export structurally uniform (every key always has a section, even if a synthetic one) while still faithfully preserving what was actually in the source file.