глобальные переменные конфликтуют между исходными файлами TCL

Сразу приходят на ум две идеи: попробовать пространства имен или интерпретаторы.

Разделение скриптов с помощью пространств имен

В этом случае мы просто делаем:

namespace eval A {
    source script-a.tcl
}
namespace eval B {
    source script-b.tcl
}

Не гарантируется, что они не будут конфликтовать — они не сильно разделены, — но они могут работать. Это определенно легко попробовать в первую очередь, и созданные переменные и процедуры должны быть разделены.

Разделение скриптов с помощью интерпретаторов

Этот метод определенно изолирует скрипты друг от друга, но с ним может быть сложнее работать, поскольку он также изолирует их от остальной части вашего приложения (если вы не предоставите соответствующие псевдонимы перекрестного взаимодействия):

interp create Acontext
interp eval Acontext {
    source script-a.tcl
}
interp create Bcontext
interp eval Bcontext {
    source script-b.tcl
}

Как я отметил выше, это не позволяет сценариям видеть что-либо, сделанное основным сценарием по умолчанию; отгораживание почти полное. Чтобы предоставить доступ к команде в основном интерпретаторе, вам нужно сделать псевдоним:

proc mainContextOperation {callee args} {
    puts "this is in the main context called from ${callee}: $args"
}
interp alias  Acontext DoMyThing  {} mainContextOperation Acontext
interp alias  Bcontext DoMyThing  {} mainContextOperation Bcontext

Сделайте эти псевдонимы до того, как вы сделаете вызовы source (но после вызовов interp create), и эти скрипты смогут использовать команду DoMyThing для вывода сообщения, в то время как основной контекст будет иметь действительно хорошее представление о том, что происходит.

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