"Anyone who uses YAML long enough will eventually get burned when attempting to abbreviate Norway."
NO: Norway # boom!
This, along with many of the design decisions in YAML strike me as a simple vs. easy tradeoff, where the authors opted for "easy," at the expense of simplicity. I (and I assume others) mostly use YAML for configuration. I need my config files to be dead simple, explicit, and predictable. Easy can take a back seat.
As the saying goes, "there are only two kinds of languages: the ones people complain about and the ones nobody uses." YAML, like any language, isn't perfect, but it's withheld the test of time and is used by software around the world—many have found it incredibly useful. Sincere thanks for your contribution and work.
It's just so blatantly unnecessary to support any file encoding other than UTF-8, supporting "extensible data types" which sometimes end up being attack vectors into a language runtime's serialization mechanism, autodetecting the types of values... the list goes on and on. Aside from the ergonomic issues of reading/writing YAML files, it's also absurdly complex to support all of YAML's features... which are used in <1% of YAML files.
A well-designed replacement for certain uses might be Dhall, but I'm not holding my breath for that to gain any widespread acceptance.
 Present tense. Things looked massively different at the time, so it's pretty unfair to second-guess the designers of YAML.
That doesn't help you, of course, when using a multitude of existing systems whose yaml parsers are based on 1.1...
I'd still love for a better means to resolve ambiguities like this, but I've found always quoting to be a fairly reliable approach.