Не совсем ясно чего ты добиться хочешь... Ведь процедуры, передающиеся в AddRegionProc вызываться движком будут, и откуда движок тогда будет брать аргументы для этих функций? Если же аргументы известны на момент вызова AddRegionProc, то что мешает создать "процедуру с состоянием"? Что то типа

variable fstat1;
variable fstat2;
variable fstat3;
variable fstat4;

procedure set_proc_state(variable a, variable b, variable c, variable d)
begin
  fstat1 := a;
  fstat2 := b;
  fstat3 := c;
  fstat4 := d;
end

procedure f1
begin
  Set_Text_Color_Green(fstat1,fstat2,fstat3,fstat4);
end

procedure f2
begin
  Set_Text_Color_Red(fstat1,fstat2,fstat3,fstat4);
end

procedure some
begin
  set_proc_state(str, n1,n2,num);
  AddRegionProc("REG", f1, f2, f2, f2);

  set_proc_state(str1, n11,n21,num1);
  AddRegionProc("REG1", f1, f2, f2, f2);

  // на самом деле теперь для события "наведение мыши" для региона "REG"
  // будет вызыватся не Set_Text_Color_Green(str, n1, n2, num), а Set_Text_Color_Green(str1, n11, n21, num1)
  // ибо состояние одно, и мы его строчкой set_proc_state(str1, n11,n21,num1) изменили.
  // Посему нужны переменные, хранящие состояние каждого региона, и процедуры, которые будут
  // передавать в Set_Text_Color_*, данные соответствующие региону.
end

Если можешь, изъясни четче свою идею, и желательно в конкретном приложении.

ХМ, реализовано, говоришь?... У меня, например каша-малаша вот такая вылазит после нескольких движений мышью
http://xmages.net/out.php/i152954_.JPG

Да и к тому-же еще в неправильном порядке координаты региона перечислены, поэтому регион имеет не прямоугольную форму, а форму двух треугольников, основаниями лежащих на двух горизонтальных сторонах прямоугольника, и сходящиеся вершинами в центре этого прямоугольника. Чета типа этого
http://xmages.net/out.php/i152970_1.JPG
Вершины нужно обязательно перечислять по часовой стрелке! Причиной этому служит формула, которая используется для просчета попадания точки в многоугольник.

Каша-малаша вылазит, ИМХО, из-за того, что вызовы GotoXY() и PrintRect() вызываются не обязательно друг за другом, и за вызовом GotoXY() для одного региона может следовать вызов PrintRect() для совершенно другого региона.  Это нужно выяснить достоверно, а пока объявление процедур R_01, G_01 и т.д. критическими решает эту проблему.

Что до удобства... По-существу сам язык позволяет обрабатывать такие выражения, но увы, компилятор подкачал. Невозможно индексировать переменные (хотя к внутренним переменным доступ именно по индексу осуществляется), нальзя брать адрес процедур (это тоже сложности никакой не вызывает). К тому же нет строгой типизации, которая помогла бы еще на этапе компиляции выловить множество ошибок. Именно поэтому  конструкция вида

AddRegionProc("REG", Set_Text_Color_Green(str, n1, n2, num), Set_Text_Color_Red(str, n1, n2, num), Set_Text_Color_Red(str, n1, n2, num), Set_Text_Color_Red(str, n1, n2, num));

допустима в терминах интерпретатора, но не допустима в терминах компилятора. Попробую доказать:

=========================================

variable begin
            //индексы, по которым осущ. доступ
n11;      //0
n21;      //1
str1;      //2 и т.д.
num1;
proc1;

n12;     
n22;   
str2;     
num2;
proc2;

end

procedure init //инициализируем указатели на обработчики
begin
  proc1 := @reg1; //получаем адрес процедуры
  proc2 := @reg2;
end

procedure reg1
begin
  GotoXY(n11, n21);
  PrintRect(str1, num1*7, 0);
  ShowWin;
end

procedure reg2
begin
  GotoXY(n12, n22);
  PrintRect(str2, num2*7, 0);
  ShowWin;
end;

procedure setup_region( variable reg, variable n1, variable n2, variable str, varaible num)
begin
  variable n;
  n := extract_n(reg); // получаем из имени региона смещение в таблице
  svars[n] := n1;        // устанавливаем состояние региона
  svars[n+1] := n2;   
  svars[n+2] := str;
  return svars[n+4]; //возвращаем адрес обработчика
end

procedure main
begin
  AddRegionProc("REG1", setup_region("REG1", 100, 200, 300), 0, 0, 0);
  // должен скомпилироватся в
  // я опускаю операции пуша в стек адресов возврата
  // stringop "REG1"   //аргументы для AddRegionProc
  // stringop "REG1"   //агрументы для setup_region
  // intop 100
  // intop 200
  // intop 300
  // intop 4               //кол-во аргументов
  // intop @setup_region
  // call                    //после выполнения, на вершине стека должен быть адрес соотв обработчика
  // intop 0               //продолжаются аргументы для AddRegionProc
  // intop 0               //здесь 0 не обозначает, что процедуры не передаются, они означают нулевую процедуру!
  // intop 0               //а нулевая процедура у нас всегда checkPartyMembersNearDoor!
end

=========================================

В таком виде все прекрасно должно работать, но, увы, компилятор такой код не продуцирует Что еще интересно, так это то что имя процедуры в разных контекстах обозначает разное поведение. Для движковых ф-й имя процедуры интерпретируется как взятие ее адреса, а для внутренних - как вызов!

Вот такие вот пироги... Я как раз занимаюсь облагараживанием компилятора, пытаясь добавить немного нового и нужного - массивы, взятие адреса процедур, структуры (). В дальнейшем - сгибание языка в сторону ООП - наследование, инкапсуляция и проч... Ну пока это все на уровне концепции, и я прощупываю возможности ssl. Основной, на данный момент тормоз - отсутствие нормального импорта процедур, я уже поборол...