ну готов только добавить некоторое к предыдущему оратору

Свой allocator is the must. На этом BLK Dragon не сильно остановился, а я пожалуй остановлюсь. В Lua очень легко (особенно если не думать -- а это модно при использовании скриптовых языков) сделать кучу аллокаций (говорим привет фрагментации и fps drop из-за garbage collect) и кучу ликов.

Свой аллокатор поможет не только локализовать проблемы, но и пошустрее их искать. Плюс -- учить мат часть. В итоге в одном из проектов после недели ковыряния добился того что gc был вообще отключен. Ценой небольшого хацка на выходе\входе в левел -- но всё же малой кровью. Так что память в lua большая, но вполне решаемая проблема.

Про взаимодействие. Всякие luabind и прочее кроме того что тянут всякое, как правило написаны на "плохом" c++ -- по моему именно его собрать так и не удалось программисту который его сильно хотел. Плюс, как всегда, свой велосипед сильно лучше по причине того что в нём ровно то что надо, код его известен и изучен, и его можно вполне ковырять в случае если что-то идет не так \ вы хотите по-другому. Ибо ваши коспромиссы слишком часто отличаются от компромиссов разработчиков библиотек.

Про связку. Сразу, во-первых, отправлю в game programming gems 6 -- там целая статья на тему -- сравниваются разные реализации.

Из своего опыта есть печальный опыт с ООП на lua, когда доблестные программисты решили использовать чей-то модуль, который в итоге на каждый вызов "виртуальной" ф-ии делал порядка 10 тысяч аллокаций. В следующем проекте переписал на классы попроще, механизм потом кое-как допилили и довели до состояния когда память вообще не выделятся (ну кроме создания собственно "объекта"). Так что вполне себе возможно. Но опять же, лично я -- против ООП в луа -- сами по себе принципы всё таблица и функции - first class citizens дают гораздо больше чем чистый ооп. Да и получается красивше.