QLua + C#

ну-ну...
а вот разработчики (не буду тыкать пальцем...) - обернули всё это критическими секциями - и сидят умничают на сайте...
дальше сказать - не могу. бо как черевато...

в качестве одного из вариантов: вам надо создать наследника от класса на c# в котором вдобавок хранить Lua_State, далее в конструкторе шарп-ового класса - обернуть получившуюся приблуду в метатаблицу и работать с ней из QLUA - соответствующе. Все методы вашего шарп-ового класса - будут методами этой метатаблицы.
истинный геморрой - вы познаете когда вам захочется работать с событиями вашего класса на с#. Там уже будет всё далеко непросто.

Если михаил прав, то можно библиотеки C# открыть в потоке main.
Так как предпочитаю С и С++ вместо С#, то так не делал, это лишь предположение.

Спасибо все большое. за ответы.

Вечер добрый. Однако хороший вопрос вы подняли. А вы не поделитесь кусочком кода чтобы обновить память.
Был личный эксперимент года 2 назад. Остановился почти сразу, когда WinForms под Quik отказались выводиться. Далее доблестный C++ и IPC. Тут можно быть уверенным, что никаких сюрпризов потери времени на десериализации или маршаллизации не будет.
Вообще говоря, конечно, выглядит сложноватым вызов методов управляемого кода из QLUA. Переход через границу управляемого/неуправляемого кода самое дорогое удовольствие.
Вычислительные функции для  Qlua лучше написать на C/C++. Разница в производительности будет огромной по причине как раз названной границы. Ну, и не забывайте про про SIMD/AVX, которые в .Net 4.5 не доступны). Может, я немного ошибся. Но что-то подсказывает, что наиболее вероятно все именно так. Использование luanet представляется обоснованным только для передачи данных в C# приложение или наоборот получение от него команд (прямолинейно loadstring()), а, допустим выгрузку потока данных в обработчике событий терминала, но по-видимому C API.  В обоих случаях интересно, как физически реализуется взаимодействие и интересно будет сравнить C API / IPC .Net и способ реализации luanet.