Personally, I’ve found excessive nesting to be problematic, because each level of nesting is an invariant, which might not fit your application anymore as it evolves.

For example, let’s say you’ve got “application.logging.enabled” as one flag.
Then you decide to introduce more extensive telemetry in the next release. So, if you go with ‘proper’ nesting, you’d have to call the flags for that:

• application.telemetry.metrics.enabled
• application.telemetry.tracing.enabled

Theoretically, you’d have to move the logging config also under that nesting level, but that would break existing configs.

Obviously, this example is relatively easy to avoid by not introducing the nesting in that case.
But you can find other examples where you might have called that level one way and then later ended up introducing a bunch of configs under a different name, where it could’ve also been under. That will confuse end users who try to configure your application and also might make it just more difficult to remember or guess config names in general, when you also have to guess the intermediate levels.

Gross

The only gross thing I see is your indentation. I find the TOML to be more readable honestly.

In a config format, you want to group top level fields together, and it enforces that. Your example could be like this instead:

lintDebug:
  stage: build
  script:
    - ./gradlew -Pci --console=plain :app:lintDebug -PbuildDir=lint
  artifacts:
    paths:
      - app/lint/reports/lint-results-debug.html
    expose_as: "lint-report"
    when: always
  interruptible: true

It’s easy to tack stuff on like that, and it’s also easy to miss when quickly scanning, especially if you’re using 2-space indenting.

The TOML would be the same in either case, because it forces related fields to be grouped separately from child groups.

The main thing I don’t like about TOML is yellow table groups:

[[thing]] 

[[thing]] 

I rarely see it in the wild though.

IMO JSON5 is the best:

It’s trying to do two things at once, and ends up doing neither very well. The extra curly braces are there because it’s trying to be a data format, and it’s bad as a data format because it’s not universal. We’ve standardized on JSON as a community for data, and that’s unlikely to change, so we shouldn’t try to “fix” it just for configs. IMO, either use JSON or a config-specific format.

I agree that YAML is plain awful. It shouldn’t exist.

XML is awful for anything outside of markup, and even then I think we can do better. I’m partial to Lua tables:

    {x=10, y=45, "one", "two", "three"}

A typical HTML drop down menu {pulled from MDN):

<select name="pets" id="pet-select">
  <option value="">--Please choose an option--</option>
  <option value="hamster">Hamster</option>
  <option value="parrot">Parrot</option>
</select>

Could be like this in a Lua table:

{
  node="select", 
  name="pets", 
  id="pet-select", 
  {value="", "--Please choose an option--"}, 
  {value="hamster", "Hamster"}, 
  {value="parrot", "Pattot"}, 
} 

Or maybe something a little different with the node type outside:

select{
  name="pets", 
  id="pet-select", 
  option{value="", "--Please choose an option--"}, 
  option{value="hamster", "Hamster"}, 
  option{value="parrot", "Parrot"}, 
} 

I think QT Quick uses something like that, but it’s been years since I played with it.