No it's YAML's fault - the fact that type coercion was once part of the serialization spec and not part of an adjacent schema spec is a tragic mistake. Now there's a bunch of outdated parsers that exhibit the issue and some that have it fixed. Meaning even more inconsistency and frustration. In an ideal world, YAML just shouldn't exist.
Even having any type coercion is a huge mistake. A true/false shouldn’t accept 0 or “false” with quotes or False with a capital f. It should be true or false. A single line string should accept one kind of quotes and one way of escaping.
Similarly in xml it’s a curse that
<Foo><Bar>1</Bar></Foo>
and
<Foo Bar=”1” />
are semantically the same but considered different in most systems.
Just avoid ambiguity and make it impossible to face a choice. The same semantic meaning should have one expression.
Oof. That's YAML 1.1. Need to use a 1.2 loader, which should have much better defaults around types. No more Norway problem unless explicitly opted into. We should badger^Wencourage our libraries to stop relying on a spec that's 14 years and multiple versions out of date.
The norway problem is way overstated, people didn't learn YAMLs reserved words and got mad when it did what it said on the tin. If you
know the type specify the type and YAML will happily err when you put a square peg in a round hole. Better yet actually validate the types when you ingest a document! Pfft who would bother with that? Recent versions of Ansible will now force you to do it right and not accept numbers when it expects a string. I believe the Prometheus ecosystem does it as well.
When it comes to config formats this is pretty reasonable. People are just primed to expect true/false to be reserved.
---
enable_frobulator: yes
use_thopojog: no
This was also the issue presented in the OP where they were mad that their version which is a string was interpreted as a number because it wasn't in quotes. Like I don't know how you expected YAML to fix that for you. If you don't quote a number in TOML it'll also be wrong.