I'm not an expert by any means, but I'm pretty sure that Ansible uses vanilla YAML (no 'bastardization').
Your first example is an Ansible convenience feature, it's not extending or changing the YAML syntax in any way. You can simply specify `cmd` values as lists or strings, since working with one or the other may be easier depending on the use case.
The templating is unfortunate in some areas, especially where the jinja2 syntax conflicts with what YAML expects (for example starting an object with '{'). That's due to a combination of templating engine choice and YAML, though, and not some custom implementation of YAML. Unless I'm misunderstanding?
I do think going with YAML was a trade-off for Ansible, but it's hard to see Ansible getting to where it is today if it had gone with a custom DSL (or JSON, thank god). I'd take Ansible's YAML over Chef's Ruby or CloudFormation's JSON any day.
Oh god, Ansible is exactly why I don't like YAML or Jinja2. I never know what needs to be quoted, what's inlined, what needs to be wrapped in "{{ }}", and what expressions are supported. But once you get the syntax right, it works great.
SaltStack also has the JINJA2 template embedding which can make it very difficult to understand which parts of the lifecycle run through templating. I'm still not certain I understand how it works.
The most recent offenders for bastardizing YAML I have seen are the different CI services:
* Circle CI using moustache-like templating and interpolation with things like {{ .Branch }} available in certain steps [1]
* GitLab CI adding an "include" type directive to declare YAML dependencies [2]
I've also experienced this professionally. At my last company, somebody decided to add a feature to enable interpolation in some parts of the YAML deployment data. It ended up being used by a handful of people who were confused why interpolation worked in some places and not others. The weird trend of "extending YAML" seems to be going against any sort of benefits you might have by trying to use it.
You can usually use plain old JSON anywhere where YAML would be used (e.g. host vars, group vars, vars file includes, I think even playbooks). And internally, most everything in Ansible is JSON anyways.
YAML is for convenience for hand-editing configuration/task files; if you're doing anything that doesn't require hand editing/readability, use JSON.
Ansible extends yaml so that:
cmd: a b c
is actually but not quite identical to:
cmd: ["a", "b", "c"]
It also embeds JINJA2 templating part-way (!) through the YAML parsing process.
The gotchas that these and other bastardizations cause is only partially documented at the bottom of this page: https://docs.ansible.com/ansible/latest/reference_appendices...
I like ansible, but its decision to use a bastardized YAML is a major pet peeve of mine.