Завидую тебе. Не скорости разработки и отношению к ней )

Зависть - это зло.

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

Сейчас просто обобщение опыта накопленного.

Ну, и с одновременным подтягиванием на современные возможности делфи.

В жизни на реальных проектах всё чаще всего просто и тупо. Поддерживаемый, переносимый и простой как пробка код - самое-самое главное. Посмотрел, мормот написан круто, но слишком замороченно, любые изменения ломают всю работу. На fpc транке просто не стартует

Это фактически приговор. Но куски забрать можно. Вот pdf им генерирую уже

Synops pdf

Поддерживаемый и простой как пробка код - самое-самое главное. .... любые изменения ломают всю работу.

вот я всегда и топлю против хрупкого кода...
и чтобы нужно было не МЕНЯТЬ,  а ДОБАВЛЯТЬ... Open/Closed Principle - открытый для расширения, закрытый для изменения -т.е. чтобы расширить функциональность, не надо было изменять существующий код... не будешь изменять - не будет (не должно) ломаться

это приговор опенсорсу ))
но "энтерпрайз", будь добр, пили )))

Я стараюсь не связывать между собой логические части, отвечающие за разный функционал.

Вот! Именно это и пытаюсь сделать)

Честно говоря, не понял, о чём дискуссия. Есть разные архитектурные решения, в основе которых были заложены какие-то принципы. Одни тебе походят, другие нет. Хорошо, если получается взять готовое, а при необходимости допилить напильником. Но иногда люди делают ставку на вещи, которые изначально не заточены на то, что понадобится в будущем. Сериализаторы которые я видел, заточены на RTTI. Но правда в том, что не все типы, которые необходимо будет поддерживать, умещаются в RTTI. И не всеми компиляторами. Например, раньше не поддерживался RTTI для указателей. Нет понятия «глубины указателя», т.е. PChar и PPChar - это принципиально разные типы, разные условия конвертации, это не просто указатели. В FPC не генерируется RTTI для методов интерфейса, хотя это сверх мощная штука. А в Delphi для некоторых методов RTTI может не генерироваться, если они не удовлетворяют определенным условиям. Да и в целом концепция свойств отказывается учитывать случаи других соглашений кроме register, не учитывает [Unsafe] результат, с комплексными свойствами, типа TCanvas.Pixels[] вообще не понятно, что делать.

Моя библиотека разрабатывается из соображения гибкости. Когда те или иные типы можно регистрировать, задавать конвертацию, когда можно вручную переопределять набор свойств и методов, описывая их полностью. Бонусы - это компактность и скорость. Компактность пригодится для разного рода утилит и юнит тестов. Ну а скорость может понадобиться в самый неподходящий момент :)

Я бы еще разделял публичную сложность и непубличную. То есть, сложность экспортируемых структур и функций обычно имеет более решающее значение, чем сложность "под капотом". Например, архивация ZIP или кодирование звука "под капотом" очень сложная штука, граничащая с магией. Но на поверхности все очень просто, TStream и имя файла.

это называется "интерфейс" ))) "интерфейс пользователя", если хотите )

но сложность разработки/доработки к интерфейсу пользователя имеет не самое близкое отношение
а мы сейчас говорим именно о первом )

Публичную сложность учитывают) Мой девиз "Чем меньше кода, тем лучше")

Сложность разработки интерфейса пользователя тоже учитываю)

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