Glad to see your comment. Not sure I get you right. I also do not like many data notations and formats floating around. I hope there's one notation that can unify all the data that I'm concerned with. That's why I created Mark.
Option 2 looks cleaner for configuration kind of usage. However, Mark is designed to be embedded in a scripting language, and used beyond just configuration files. Unless the scripting language uses indentation as delimiter, like Python, option 2 will not work.
Personally, I prefer C/Java/JS family of languages that has insignificant whitespace. So Mark is designed to use explicit delimiters '<' and '>' to enclose an element.
Hope that explains one of the most important syntax designs of Mark.