Уже неактуально.

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

Это реализуемо, и дёшево. Прототип с тестами написан и прошёл ревью; в мастер не пойдёт, раз потребности нет, но выводы такие:

1. Вся инфраструктура в коде уже есть: bz_check_regexp валидирует пользовательский паттерн на том же сервере БД, который будет его исполнять (при ошибке — внятная страница «Недопустимое регулярное выражение»), а REGEXP в MariaDB (PCRE2) незаякорен, т.е. просто qt4 означает то самое *qt4* из описания — glob-синтаксис не нужен.

2. Опасения не подтвердились (проверено на копии продовой базы, MariaDB 12.3): ReDoS не проходит (внутренние лимиты PCRE2 + имена компонент короткие), протухший/некомпилирующийся паттерн из таблицы даёт NULL построчно — правило просто замолкает, не ломая рассылку остальным; правил в user_announce_map ~330, производительность не вопрос.

3. Нюансы, которые всплыли на ревью: components.name — колонка с _bin-коллацией, матчить надо через COLLATE utf8mb3_general_ci (иначе qt4 не найдёт PyQt4); паттерн длиннее varchar(64) надо отклонять до INSERT (сервер молча обрезает).

Объём: колонка component_pattern в user_announce_map + миграция, валидация в userprefs.cgi, одна ветка в SQL subscribers_list, поле в форме (en+ru) — суммарно ~70 строк кода и ~100 строк runtime-тестов.

Побочный улов ревью: действия на вкладке подписок не проверяли CSRF-токен, а все тексты ошибок подписок в браузере рендерились как «Error string not found» (лежали в ветке шаблона, исключённой для ERROR_MODE_WEBPAGE). Эти два фикса живут независимо от фичи и уйдут отдельным PR.