а)

интернал-софтваре это отдельная тема)

Ну оно коммерческое но малоизвестное за пределами госструктур.

А как идет работа с модулями\зависимостями для плагинов? Если .lua скрипт делает вызов require, то он должен срабатывать относительно папки с плагином. Как я понимаю, этот путь можно добавить к путям с либами из d-кода через package.path. Второй вариант - сделать глобальную переменную с путем к директории плагина и установить её через lfs.chdir, хотя этот какой-то такой себе вариант. Но есть еще и сторонние модули, там же lfs, потом нужен luautf8 для нормальной обработки строк и эти зависимости разные на разных системах. Пытаться ложить\класть какие-то из них в директорию с плагином, или устанавливать через LuaRocks...

Имхо, самый рациональный вариант это package.path/cpath. Там две переменные, одна для подключения луёвых, другая для сишных либ.
Насколько я знаю, lfs.chdir не повлияет на работу require, только на внутреннюю модель lfs. Хотя я сейчас проверю.

А, не, lfs.chdir вполне себе влияет. Прям на самом деле переключает рабочую директорию. Правда, в package.path должно быть прописано что-то типа ./?.lua;

да, этот вариант сработал и без дополнительных модификаций, возможно, там по дефолту есть /?. А вот с package.path возникли определенные вопросы,  получается что-то такое аналогией https://stackoverflow.com/a/5519398 и похожие варианты, через luaL_dostring просто так работать не будет.

Почему не будут?
luaL_dostring(L, "package.path = package.path .. ';?.lua'"); должно сработать и удовлетворить основные потребности, если дёрнуть после инициализации стандартной либы.
Можно и через setenv, но вероятно эффект будет если дёрнуть ДО инициализации стандартной либы.

Сейчас не вспомню, но вроде бы у меня он тоже не сработал как и пишут там люди в комментах: "I tried this, but luaL_dostring returns and error. The message I get is attempt to index a nil value (global 'package')"

Это из-за того что слишком рано дёрнули, не инициализировав стандартную библиотеку.

Да, как вариант забыл luaL_openlibs(L)

нужно будет проверить

В целом, по луям есть чатик pro.lua, там можно задавать кучу вопросов, если тут это страшно/не по правилам и т.д.

Спасибо. Если я когда-нибудь доберусь до NodeMCU Lua и они не поменяют стек на микропайтон\еспруино\js\etc, то возможно тогда и займусь луем еще плотнее). Пока нет особых кейсов на это дело, изучаю связку с D. Все же с плагинами десктопный ди становится поприятнее.

Проверил, вроде заработало через luaL_dostring, значит в прошлых экспериментах все-таки где-то напутал. Так оно поприятнее выглядит.

io, package, table, string, coroutine и всякое такое — глобальные таблички с функциями стандартных либ, добавляются в стейт они только и исключительно через openlibs : )
Без дёрганья openlibs можно получить чистый незамутнённый луа-стейт для простейших задач вроде арифметики или разметки простых функций/колбеков function mycallback(a, b, c) if a then return true end, чего может хватить для простой логики в плагинах (без работы с текстом, таблицами, внешними модулями и ио, разумеется).

ммм.. десктопное приложение маловероятно, что будет работать с правами рута, хотя всякие есть, но все-таки, а насколько практикуется приложение под рутом + плагин под пользователем? Это, по идее, открывает широкий набор возможностей для самых разных атак. Любопытно, D-приложение более устойчиво или же нет.

Любая система любых плагинов это уже готовая атака. Особенно если можно подрубать сишные плагины (dll/so-либы).

Хотя бы через подмену содержимого скриптов.

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