XML might work if it was well-formed and laid out neatly as per a custom DTD, but that's just extra hassle for the sakes of getting XML to work.

Furthermore, I have seen some weird XML configuration files that go along the lines of this (forgive me if this isnt valid XML, it's only a crude example).

<xml>
 <file1 perms="rxwrwxrwx" contents="invoices for the month of may">/pa
+th/to/some/file1<file1>
 <file2 attributes="hidden from floor staff" expires="Mar,2007" conten
+ts="company downsizing plans">/path/to/some/file2<file2>
...
</xml>
[download]

That opposed to the micro$oft .INI fmt

[File1]
File=/path/to/file1
Perms=rwxrwxrwx
contents="invoices for the month of may"

[File2]
File=/path/to/file2
Attributes="Hidden from floor staff"
Expires="Mar.2007"
contents="company downsizing plans"
[download]

The latter not only looks neater, information is easily gleaned out of it when a human reads it. Less is likely to go wrong with it too, IMO and (Tongue in cheek) it also takes up less disk/memory space. :)

Well, I'm a fan of XML (for various reasons) if it's machine-generated and machine-read, I'd consider it in in-house config-files (as long as staff were XML-savvy), but if I wanted to save support staff the headache of dealing with an external XML-unsavvy user, I'd use .INI or something along those lines. XML is just not worth the hassle if you are going to have other people meddling about with it.