Useability is not good

100% agree. I really hated that back when I was still using SaltStack. In SaltStack, unlike Ansible, the templating happens on the "whole file" level of the YAML rules/roles, meaning it'll be interleaved with regular YAML stuff — often completely breaking formatting, linting etc., as you said.

For example, in SaltStack you could do something like this to distribute two files:

{% set file_list = [ 'vimrc', 'bashrc' ] %}
{% for item in file_list %}
/etc/{{ item }}:
  file.managed:
    - source: salt://{{ item }}
{% endfor %}

In Ansible templating can only be used in YAML values, though, meaning they're always part of a YAML string. In order to provide basic loops & conditions Ansible itself has special hash keys it recognizes, evaluating the template code in the corresponding values & making the decision based on it. For example:

- ansible.builtin.file:
    src: "files/{{ item }}"
    dest: "/etc/
  loop: "{{ file_list }}"
  vars:
    file_list: [ 'vimrc', 'bashrc' ]

You're correct that with additional, out-of-band information you can map it unambiguously, but there's out-of-band info for other formats, too, e.g. JSON schema.

What I meant was that the following XML cannot be read by naive parsers & converted into hash-array structures without an additional information such as a stylesheet or hints to the parser:

<xml>
  <settings>
    <something>42</something>
  </settings>

  <auth>
    <option/>
  </auth>
</xml>

First of all, the program might expect <settings> to be either a hash or an array; it't not obvious just from a stylesheet-less XML alone. Here are two possible corresponding JSON representations:

{
  "settings": {
    "something": 42
  }
}

or even

{
  "settings": [
    { "something": "42" }
  ]
}

Second, there's no info about the type of <option> either. It might be: an empty string; a None/undefined/null type of value…

Of course this is because XML is capable of expressing more complex structures than nested hash-arrays, but most programs nowadays use nested hash-arrays for any kind of configuration information — because it's more or less natural to build such structures, they're trivial to implement in most programming languages, they map cleanly to all kinds of binary & text representations. XML's flexibility & capabilities are to its detriment when considering to use it as a human-maintainable configuration format.

For me an ideal human-maintainable format has a couple of properties:

• allows for comments (JSON loses here)
• has in-band structural information to make tooling a viable option (pretty printing, structure validation, auto-indenting in an editor, easy navigation with "jump to key XYZ…" functionality; YAML loses here)
• makes it harder to mess up the format (YAML & XML lose here)
• does have little repetition in what I have to type all the time (XML & TOML lose here)
• is optically easy to grasp for us meatbags, not just agile computers (YAML loses here, but so does JSON when you have to deal with long strings)

I did not actually know about textproto which NYKevin has just mentioned. I will definitely look into that.