1/ кстати галлантное решение - запретить "a" - хотя и грубое)

Да, об этом и речь. У нас в системе много не гласных правил на именование переменных / плагинов / категорий. (например нельзя сощдать плагин с именем admin). Здесь (конкретно в этом месте) мы просто эти правила формализуем.

2б - нельзя. ведь можно нарушить совместимость. и еще усугубить, если код плагина и модуля одинаковые. 

На сколько я помню у нас не может одновременно работать плагин и модуль с одним кодом. Поэтому конфликта здесь не будет.

единственное решение для плагинов выглядит сейчас так:

cot_auth('plug', 'plugname', 'RWA', 'catname')  - а это выглядит ужасно!

Добавлено 4 минуты спустя:

хотя может сделать хитрый обработчик внутри auth

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

2б - нельзя. ведь можно нарушить совместимость. и еще усугубить, если код плагина и модуля одинаковые. 

единственное решение для плагинов выглядит сейчас так:

cot_auth('plug', 'plugname', 'RWA', 'catname')  - а это выглядит ужасно!

Добавлено 4 минуты спустя:

хотя может сделать хитрый обработчик внутри auth

1. Дублирование записей о правах при создании категории «а». Оно и логично одна запись это админская (общий доступ к модулю), вторая это доступ к категории. Это баг. Таких узких мест в системе (когда нельзя использовать некоторые ключевые слова) много. Речь здесь, на сколько я понимаю, не идет о изменении «а» на «__def», а о запрете использования некотрых слов в коде категории.
2. При создании категории для плагина (и именно для плагина) через `cot_structure_add` не создаются права. Это объяснимо тем, что по умолчанию они создаются только для модулей.
   Тут есть 2 момента:
     а). Надо разделять общие права на доступ к плагину и права на доступ к конкретной его категории
     б). Из приведенных тобой вариантов логичнее (для категории) использовать cot_auth('page', 'catname', 'RWA') — по аналогии с модулями (тем более речь идет о их возможном объединении в будущем).

так как мы заменим a на __def - и потом придет ответ что ошибка с этой категорией.

права  в плагинах - специально не устанавливаются. Я пытался это сделать гибко, однако не вышло - это был единственноый вариант. С ним и траст тогда согласился.

В целом добавив плагинам права = это автоматически убирает практически все различия между плагинами и модулями. А значит, надо объединять апи. Это весомая работа. но имхо необходимая

Добавлено 1 час спустя:

а вопрос там в функции cot_auth('plug', 'plugname', 'RWA') против cot_auth('page', 'a', 'RWA') против cot_auth('page', 'catname', 'RWA')

Обнаружил такой неприятный момент. Если в структуре любого модуля создать категорию с кодом 'a', то права для этого модуля устанавливаются дважды! Посмотрел в таблице cot_auth, там появляются дублирующие записи для прав на модуль. Нужно обязательно запретить использование кода 'a' при создании категорий!

Также заметил, что при создании своей структуры для определенного плагина (при разработке), то для этой структуры не создаются права (функция cot_structure_add() )! На мой взгляд это не гибко. Предлагаю добавить возможность устанавливать права не только для струткур в модулях, но и для плагинов тоже.