Про валидацию данных...

С одной стороны есть стандарт который говорит как должно быть, с другой стороны есть несколько велосипедов на дельфях которые уже используются (некоторые аж 15 годиков) и кое-что грубо нарушают. Юзеры страдать от этого не должны, но и поощрять нарушение стандарта не хочется.

Если ИТ-стандарт расходится с ИТ-реальностью то это безусловно проблемы стандарта. Забей на него и делай так чтоб понимать реально существующие файлы. И вообще, в нормальных стандартах на формат всегда есть оговорка: при генерации, старайтесь быть максимально строгими, при парсинге - максимально толерантными (но не в ущерб функционалу).

Лепить проверки к многим функциям и полям? Скажем пусть у нас будет поле Email тогда делать функцию CheckEmail

Это и дальше совершенно непонятно без контекста. Если ты таки объяснишь, что за формат файла ты парсишь и для чего - наверно станет понятнее.

Описание надмозг конечно, два раза перечитал.

• Иметь некую хню-1 которая просто хранит все поля (ваще отдельно просто хранит в себе и всё)
• Иметь опционалюную хню-2 которой можно сказать, проверь чтобы поля А,Б,В,Г,Д были заполнены правильно, а если из них какие неверны верни мне их список. По итогу

что_то_главное_тут_делается(тут_что_то) // хня 1 собирает незаметно в себя инфу

// и теперь разраб может вызравать на своё усмотрение твой валидатор
тип массив = А,Б,В,Г,Д
if (вывод = проверить_поля(массив)) != ничего 
{
   вхиле ин вывод
   принты_попапы(ой поле вывод.имя имеет какашку в виде вывод.значение исправляйте )
}

Суть, да, пиши изкоробочный валидатор который можно будет просто взять и всё, а можно и не брать, а использовать свой.

Если один хрен так или иначе надо проверять данные, просто нет никакого смысла не писать валидатор так как его будут писать все полюбому, значит он просто должен быть, простой как палка при этом, кому надо гибкости и своего напишут свой, но практика показывает что в большинстве случаев нужно простое и топорное решение из коробки, а всё остальное это всё остальное.

Да пиши для 100 полей проверки, да хоть для 1000. При этом основной код засирать и не нужно, для это и нужна первах хня которая просто будет хранить значения и если нужно их проверять.

А зачем его проверять? Если он НЕвалиден, то письмо для активации не придет и тп

Таким образом, проводить валидацию при чтении файла полностью согласно стандарту я не могу иначе я не буду читать файлы в которых нарушения незначительные.

Сделай два режима валидации — strict и stupid-users-shat-all-over-the-place.

Строго соблюдать стандарт и объявить это киллер-фичей.

Совсем немного оффтоп вопрос. Почему не хочешь воспользоваться https://kaitai.io/ и написать описания формата для него? Шарп оно тоже поддерживает.

Разбить на два стадии - чтение и валидацию. Причем валидация должна возвращать не true/false, а список проблем. После чего сделать маскирование нужного набора кривых полей - элементарщина.

Это называется json scheme

С одной стороны есть стандарт который говорит как должно быть, с другой стороны есть несколько велосипедов на дельфях которые уже используются (некоторые аж 15 годиков) и кое-что грубо нарушают.

Так сделай в либе 2 функции. Первая читает корректный файл и кидает ошибку если формат кривой. Вторая пытается пофиксить кривой файл, чтобы его можно было прочитать.

сделай несколько уровней валидации от строгой до ленивой.

ИМНО никого поощрять ненужно (этот мир уже не спасти) - удобная либа должна читать как можно более расширенный (изуродованный) формат и делать это по возможности молча.

Если есть неоднозначности - о них надо сказать, и сказать как они разрешены (если они разрешены). Если они не разрешены то надо упасть с диким воплем разумеется.

Если либа будет сообщать о каких то потенциальных проблемах (например формат нарушен, мы его прочли но другие могут не понять) - наверное это хорошо, но сообщение должно быть отключаемо.

Как альтернатива мб опциональная настройка насколько педантично должен выдерживаться формат.

Это называется json scheme

Где в ОП хоть слово про json?

А как собственно по-феншую это делать?

Читайте файлы, но выводите предупреждения в лог о том что файл не валиден, проблема в строке такой-то.

Но я должен поощрить тех разработчиков которые разрабатывают продукт для конечного юзера

Отсутствие предупреждений в логах, вполне себе мотивация для адекватных разработчиков.

Где в ОП хоть слово про json?

Прямо в аббревиатуре, J вначале, просто ее поначалу плохо видно также как и А (Абстракции) в конце.