AxeleronНу и еще один ссыль , где вряд ли пометят неверный ответ как правильный.
Заметьте, следующий ответ получил больше ляйков.
Но я сам не рассматриваю аргумент "так думает большинство" всерьёз и никому не рекомендую. Иначе земля до сих пор осталась бы плоской и центром вселенной.

AxeleronМои доводы против использования реестра:
1) Доступ к реестру гораздо затратен по времени и ресурсам по сравнению с тем же ini или xml. Можете сами протестить и замерять по общим параметрам, если интересно.
2) Динамические и некритичные данные не должны пихаться в реестр.
1.А. Самое забавное что сами люди майкросовта сделала эмуляцию API для INI файлов и перенаправила их в регистр.
1.Б. Скорость. Смею предположить время записи INI < Registry < XML
1.В. Аргумент против файлов: их сложно и накладно менять. Запись одного значения приводит к тому что надо переписать весь файл.
А синхронизация доступа приводит к тому что процессы нещадно тормозят. (По крайней мере это был аргумент Microsoft против ini файлов для системных нужд Windows). Подобные проблемы возникли и у линуксовых приложений и помнится были попытки в KDE сделать аналог регистру на XML. Попытка провалилась на сколько я помню. Следующий этап был создать похожую базу как и у виндовс:
Компактную, эффективную in-memory DB для конфигураций. Я давно уже не занимался Линуксом, про текущее состояние дел не знаю.
В моём случае синхронизировать сильно не требуется и файл можно переписать целиком но это все не аргументы против регистра.
2. Почему нет?

В одном я думаю у нас консес:
- Исползование .Net ConfigurationManager не подходит по причине неконфигурационных данных.
- Использование одного файла XML мерзко для обновлений.
Относительно других вариантов:
Оба имеет право на жизнь, оба в меру эффективны и засоряют диск. оба для пользователя не очевидны.
Не плохо если бы микрософт ввела стандарт для программ и их веток в регистре и при долгом отсутствии чтений чистила бы регистр автоматом.

AxeleronМои доводы против использования реестра:
1) Доступ к реестру гораздо затратен по времени и ресурсам по сравнению с тем же ini или xml. Можете сами протестить и замерять по общим параметрам, если интересно.


Из ответа можно сделать вывод, что вы проверяли. Давайте замерим вместе? Вы пишете тест для вами предпочитаемого решения, а я для регистра. Результаты тут сравним.
Это справедливо делит работу и каждый заинтересован в лучшем и корректном результате.
Идёт?

Предлагаю два теста:

1. Чтение МРУ. результат список из строк упорядоченный по времени доступа.
В списке 40 значений, каждое значение путь к файлу содержащий русские буквы.
Тест выполняется 1000 раз.

2. Обновление МРУ. в списке меняется одно из значений.
с вероятностью 40 процентов в МРУ добавляется существующее значение (поднимается на вершину списка)
с вероятностью 60 процентов в МРУ добавляется новое значение.
Запись МРУ списка происходит после каждого обновления.
Тест выполняется 1000 раз.

И кстати приглашаю всех отметившився принять участие в "conteste".
Я берусь написать тест для регистра.