> Вкусовщина чистой воды, имхо. Для хранния произвольных данных ничто не лучше, всё
> имеет свои сферы применения.

Угу. Для XML такой сферой является разметка текста. Не конфига.

>А с XML удобно работать с помощью XQuery.

На самом деле не удобно. XML и библиотеки к нему мне всегда напоминали Java тем насколько там всё погрязло в оверинжиниринге. Я хочу взять и сделать что-то типа:

Config cfg = read_cfg("~/.my-config");
Theme theme = cfg.get("app").get("theme").or(DEFAULT_THEME);

Что-то типа, не обязательно именно так. Можно скажем так:

Theme theme = cfg.get("app/theme").or(DEFAULT_THEME).

Или

theme_t theme = json_get(cfg, "app.theme") || DEFAULT_THEME;

Или даже

(defparameter *theme* +default-theme+)
(unwind-protect
    (eval (read "~/.my-config"))
  (msg "There is an error in your config, so if you see something weird, try to fix it in the config"))

Как нибудь так, без всей вот этой хрени, с именами функций по 50 символов, которые принимают не меньше пяти аргументов, половина которых задаёт режим работы функции, от чего начинаешь задаваться вопросом: нахрена было 50 символов в имя пихать, чтобы потом уточнять ещё режим работы функции аргументами? И при этом, одной функции всегда будет мало, надо будет сделать по три вызова на каждый запрос. Ах да, ещё и парсинг xml радостно и необратимо обломается, при малейшей ошибке или несоответствии dtd.

XQuery крайне неудобен без обёртки над ним. Это корпоративная хрень для разработки корпоративных аппликух на Java, которые радуют глаз эффективного менагера. Даже в javascript никто не использует XQuery, предпочитая всякие обёртки над ним, css-селекторы и проч.

Это с точки зрения API. С точки зрения пользователя xml-конфига всё не сильно лучше: объём полезной информации в конфиге минимален, потому что по большей части там сплошные угловые скобки, слеши, многократные повторы имён тегов... То есть захламлено всё так, что дальше некуда. Это мутное разделение на атрибуты и контент тега -- зачем делать и так и эдак? Никто до конца не понимает, потому у каждого своё понимание, что пихать в атрибут, что в контент: атрибут вроде удобнее, он меньше писанины требует, но нет ведь у всех какие-то глубинные идеи, типа one-to-one отношение, или one-to-many, и "может быть когда-нибудь понадобится one-to-many, поэтому давайте пользователи прямо сейчас начнут страдать от ещё одного вложенного тега в конфиге вместо няшного атрибута, а если one-to-many не понадобится никогда и страдания будут бесцельными, то нам покакать на них".