Oh if you are in a position to set up a proper XML schema/tool workflow, do that! LEON was created for our own needs and made available to anyone that aren't able or willing to make that leap from a more notepad-based workflow. And to avoid misunderstanding let me reiterate that LEON partially stems from my own desire to create something for the fun of it.
We're developing a war game where the player researches and upgrades weapons to fight waves of attacking enemies. All of the weapon and enemy details (including stats, behaviour and asset information) are stored in CSV files, and edited with open office or excel, while other information is typically stored in XML-files. Some files have multiple localized versions. Gameplay balancing is divided between one designer and a few artists, while us programmers focus on implementing the systems.
Most syntax-hiccups have been related to XML but CSV is finicky with Subversion. It's a very "horizontal" format and in practicality only one person can work a file at any one time.
Recently we've only begun to replace some of these files with LEON files, to test the stability and feasibility of the format. So far it's gone smoothly both on the designer side and on the programming side. One of the programmers have used LEON to script tutorial sequences, connecting UI elements and game mechanics.
I agree that ambiguity is bad, but I honestly don't believe LEON is a large enough format to warrant much worries about that. Some rules are implicit, yes, but only where it makes sense.
If someone writes:
description: "He was a tall and handsome man."
the parser (or I, rather) assumes they didn't want to keep the whitespace at the start of the second line, but just in case there is a way to retain that whitespace (although I'm not sure whether to keep this feature or not):
description = ("He was a tall and handsome man.")
The worst example I can think of is if someone meant to write this:
but instead wrote:
that would be a valid value to LEON but not a valid value to the game. But this isn't much different from any typo in any format, and by setting a flag in the parser you can catch this error at runtime.