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

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

К тому же, как Вы можете судить об ограниченности инструмента, вооружившись для этого ограниченным пониманием о самом инструменте? Со стороны это заявление выглядит как абсурдные утверждения "о плоской земле", людьми, с явным недостатком образования. Так что скорее именно Ваши попытки приделать ноги своему "чудовищу Франкенштейна" выглядят "костылями", нежели все те решения, которые ещё даже не попытались быть озвучены.

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

Еще раз, что имеется:

FILE.ini - это база с данными

[id_555]
game=CounterStrike
time_game=5
score_team1=2
score_team2=10

[id_999]
game=Race
time_game=60
score_team1=0
score_team2=0

Нужны проверки параметров из базы выше и записывать свой текст результата.
Но сколько проверок будет я не знаю, надо как можно проще их создать и потом добавлять/убирать.
может состоять из одной строки проверка и после будет результат, может к одному результату понадобится много проверок и +-*/ вычисление.
Их может быть грубо сегодня 2, через месяц 100.

проверка 1.

game=CounterStrike ? ok:=1 : ok:=0
x:= time_game*3.14
ok=1 AND x<66 ? result:=1 : 0
result "Все четко"

проверка 2.

score_team2 > score_team1 AND game=Race ? result:=1 : 0
result "Беда-печаль"

проверка 99.
.....
проверка 100.
.........

https://autohotkey.com/board/topic/15675-monster-evaluate-math-expressions-in-strings/

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

В моём понимании, "База Данных" - хранит данные, а логика описана отдельно от них.

Если бы я собирал на своём заводе машины разных марок, то для каждой написал бы функцию, описывающую содержание такой модели. А ещё лучше, наследуемый каскад классов, в которых для каждой опции было подробное описание кодом, а для создания конечного продукта, передавал бы в вызов метода создания машины данные из БД. Вот такое описание стоило бы сделать подключаемым файлом, чтобы не загромождать основной код.

#Include файл1.ini
MsgBox % param1 " " param2
#Include файл2.ini
MsgBox % param1 " " param2

Это все тут конечно хорошо, но тут нет проверки параметров по каким либо условиям.

Ну как вам объяснить. У вас есть много данных в базе. Они постоянно меняются, нужно в определенный момент времени найти свои значения из базы и выдать уведомление. Да можно наплодить кучу ahk файлов, которые будут подключатся в тело, но там все равно в коде будет каша.

Если на примере автомобильного завода. У вас конвеер. У вас много разных моделей может быть на выходе собранных. Собирает робот автоматически, нужно только ему задать правильные параметры под каждый автомобиль.

[ЖИГУЛИ]

двигатель = 16 клапанов
коробка передач = если КЛИЕНТ ЗАКАЗЧИК VIP тогда АВТОМАТИЧЕСКАЯ иначе МЕХАНИКА
лампочки = галоген
координаты установки двигателя = "5 метров длина авто" минус "длина капота"

[БУГАТТИ]

двигатель = 32 клапанов
коробка передач = АВТОМАТИЧЕСКАЯ 
лампочки = ДИОД
координаты установки двигателя = "6 метров длина авто" минус "длина задних фонарей*3"

Робот прочитает эти параметры, сверит есть ли они в наличии на складе и соберет тот самый нужный авто. Если на складе нет нужного двигателя, он просто ничего не сделает.
Если мне нужно создать ВОЛГУ я просто добавлю в конфиг новую запись с параметрами. База данных (склад) остается прежней.
И мне кучу новых файлов с проверкой IF ELSE под каждое авто, создавать не нужно будет. Логика уже прописана в коде, надо только параметры перебрать из конфига.

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

По сути ведь происходит то же самое, но только через "одно место". Это даже интригует!
Зачем, уважаемый автор этого алгоритма, именно так?! В чём превосходство такого подхода? Такое ощущение, что я что-то важное упускаю из вида, или Вы что-то недоговариваете. Удовлетворите пожалуйста моё любопытство.

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

файл1 ->  B := C+E; a>10 AND B>10 -> вывод результата 1.
файл2 ->  If A>10. A := C/B; round(a) -> вывод результата 2.
файл3 ->  If A=B  -> вывод результата 3.
..........
файлN

надоело ручками писать кучу этих if else, хочется какой-то единый шаблон, чтобы один файл AHK пробежался по базе с условиями и проверил все что есть.

Скажите, какой смысл описывать условия во внешнем файле? Чем это улучшает качество кода? Или это результат вычислений другого софта, который нужно с помощью AHK обработать? Можете описать тех. задание подробней? Тогда может оказаться, что есть другое решение и не нужно городить смесь бульдога с носорогом.

Я например, вижу ситуацию так: если Вы читаете файл "файл1.ini", то даю 100% гарантию, что будет выполняться сравнение ">=", с одной из переменной, имя которой "ВРЕМЯ". Если её имя известно, тогда она на момент чтения из файла должна откуда-то получать значение для сравнения, если так, то раз известно, что это будет она, то вызывающий инструкции код, на этот момент, можно дополнить переменной с этим именем. Тогда в "файл1.ini" нужно сохранить числовое значение, потому как оно, вероятно - сохранённый результат каких-то вычислений и в файле скрипта нужно прочитать именно его, после чего выполнить уже известное сравнение:

ВРЕМЯ := 11
IniRead, timeVar, файл1.ini, Default, param1
if (ВРЕМЯ >= timeVar)
	Msgbox, OK
else
	Msgbox, Не ОК

То же самое касается и остальных случаев. И не обязательно хранить значения в разных файлах.

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