More of a reply than I was expecting.

I guess that the tabbed format doesn't make sense for the items/entites where every item/entity has every field. Then duplicating the extra tag names really doesn't make sense and just takes up space (although if you get enough of them there's the issues of duplicating the header information so you can still see it, but I guess that's just what you'd have to do.)
What I was more thinking about what your third paragraph, supporting some sensible way of merging and organizing data. At the moment, you seem to have exactly one file per kind of data, each with their own specific format. It would be nice if you could separate those out (more like the DF raws actually, although that format is even stranger than yours

) into say multiple files for special abilities, all of which would be loaded and parsed. Then you could mix and match files to get sub-mods, rather than dealing with moving around lines of individual files. Although it seems like you're thinking about that to, so power to you.
I guess part of the reason why I'm asking is that I'm wrestling with the same ideas in a few projects that I'm working on. I really like the idea of games that are basically just a strong core engine with a "default mod" that you can make do all sorts of wonderful things (a la DF or X@COM), but I'm still struggling with a data format. I'm not really sold on YAML, being personally more of a fan of JSON or S-Expression based files, but I've also toyed with the idea of pushing the configuration files all of the way to scripts, like Python/Lua or the like (similar to what Civ IV and V do). That might get really interesting. Who knows.
In any case, thanks for the explanation. One of these days I'll actually get time when I have a Windows machine (I mostly use Linux) so I can actually try out X@COM, but until then I'm really enjoying reading about your development blog at least.

It really is an awesome idea for a game/engine and I can't wait to see what you and others do with it.