Приколы vl-acad-defun и NET
Известно, что vl-acad-defun позволяет "экспортировать" лисп-функцию для вызова ее из-под arx / net.
На самом деле не только. Она же позволяет "выпустить" функцию из vlx с отдельным именным пространством.
Итак, ситуация:
- Есть vlx (в данном конкретном случае с общим именным пространством) с несколькими функциями, для которых выполнен vl-acad-defun. Остальной функционал, который болтается в этом vlx, роли не играет
- Есть NET-сборка, которая вызывает эти функции
- Есть исходники этих функций, повторно выполняющие vl-acad-defun
Последовательность загрузки проста и незатейлива:
- Загрузка NET-сборки
- Загрузка vlx
- Загрузка исходников
Здесь больше всего интересует загрузка именно vlx и lsp. Поскольку именное пространство не отдельное, повторная загрузка исходника по идее должна "перекрывать" объявление функции внутри vlx. То есть если внутри vlx есть определение some-cool-function, а потом мы загружаем lsp, внутри которого прописано (defun some-cool-funcion() <...>), то при вызове будет срабатывать именно исходник.
Так было, и это было круто. До того момента, пока в игру не вступает vl-acad-defun.
Я не понял причину, но, похоже, при описанной последовательности загрузки определение функции, которое регистрируется из-под vlx (с применением vl-acad-defun), становится "первым и единственным". И именно оно и подхватывается при вызове из NET. Автоматическая загрузка исходника не срабатывает и то ли не регистрирует, то ли неправильно регистрирует функцию.
При этом ручная загрузка исходника lsp с vl-acad-defun прекрасно перерегистрирует функцию, и при вызове из NET срабатывает именно загруженный вручную вариант.
Причину даже не стал выяснять. Нашел костыль для обхода - и пока этого достаточно.
P.S. Еще одна иллюстрация на тему, что не стоит смешивать внутри одного проекта NET и LISP. Но переписывать все проекты никто не даст - нет ни знаний, ни времени 
