Описание полей в методе on_trans_reply

Похоже, документация не соответствует реальности. Во-первых, что за странные цифры в скобках - (0x21) и (0x22)?
А во-вторых, я записывал в лог значения полей в OnTransReply, и в flags вижу такие значения:
0x260001 - при выставлении заявки на продажу.
0x240001 - при выставлении заявки на покупку и снятии любой заявки.
Отличаются они в 22 бите. Но установлен этот бит только при выставлении заявки на продажу, не на покупку.

Поскольку поддержка отмалчивается, проведу разбор самостоятельно, для себя и таких как я (хотя и слабо разбираюсь в этом), а что делать?

1. Опечатка в тексте руководства ARQA Technologies очевидна, авторы справки перепутали номера битов и шестнадцатеричные (HEX) маски. Авторы опечатались в HEX-записи. Они хотели написать бит 20 (маска 0x100000) и бит 21 (маска 0x200000). Но почему то написали 0x21 и 0x22?
Видимо механически скопировали номера битов, забыв перевести их в степени двойки и ошибочно записав номера битов 20 и 21 как 0x20 / 0x21, а затем сдвинули индексы?
Доверять HEX-значениям 0x21 и 0x22 из этой справки нельзя — они полностью неверны.

2. Ловушка Истины или почему 0 в Lua — это true? Это главная концептуальная ловушка для программистов, переходящих на Lua с языков Си, C++ или Python.
В отличие от Си/Python, где 0 — это false, любое другое число — это true.
В Lua (всех версий), логическим ложным значением (false) признаются исключительно два ключевых слова: false и nil. Всё остальное, включая число 0, пустую строку "" и пустую таблицу {}, интерпретатором Lua всегда признается истиной (true)!

Так как в терминал QUIK v11+ при работе на чистом Lua 5.4.1, встроенная библиотека bit (которая была внешней .dll в старых версиях) является устаревшей. Появилась возможность использовать родные поразрядные Си-операторы Lua 5.4.1, которые работают на уровне процессора и не тратят время на вызовы функций.
Собствено на этом можно и закончить. Хотя про это много уже писалось повторюсь. Вот золотой стандарт проверки флагов, который гарантирует отсутствие ложных срабатываний (как памятка):

Вариант 1. Проверка через родной оператор Lua 5.4.1 (&) — Рекомендуемый HFT-выбор. Оператор & (побитовое И) возвращает значение маски (например, 4) или 0. Проверяем строго через ~= 0:
-- Проверяем Бит №2 заявки/сделки (маска 2^2 = 4, то есть 0x4)
-- На Мосбирже: flags & 0x4 ~= 0 означает "Сделка на ПРОДАЖУ"
local is_sell = (flags & 0x4) ~= 0
if is_sell then
   -- Блок выполнится строго если бит присутствует (результат операции равен 4)
end

Вариант 2. Проверка через встроенную функцию bit.test в старых скриптах. Если используете функцию bit.test, она сама под капотом делает сравнение и возвращает чистый булев тип (true или false). Здесь оператор ~= 0 не нужен:
-- В функцию передается не маска, а чистый НОМЕР БИТА (начиная с 0)
local is_sell = bit.test(flags, 2) -- Возвращает true или false
if is_sell then
   -- Код безопасен, так как is_sell — это честный boolean
end

Дествительно не подумал и повелся на маркетинговые мифы о "Си-скоростях". Любое значение Lua — это сложная структура TValue, и побитовые операторы в Lua 5.4 действительно не являются прямыми ассемблерными инструкциями ЦП.

nikolz,  Спасибо за замечание и системное погружение в исходный Си-код языка. Это позволяет строить более осознанную архитектуру, понимая такт процессора.

Вывод Lua = Таблица, Lua ~= Ассемблер.

Несмотря на то, что на уровне исполнения это вызов функций ВМ, оператор & в Lua 5.4.1 работает быстрее, чем вызов старой внешней библиотеки bit.band(flags, 0x4). Следовательно вывод что встроенный оператор & всё же предпочтительнее для Квика сохраняется и это главное!