Возможность указания "прямого пути" для тест-кейса в иерархии кастомных полей

Хочу предложить идею для улучшения продукта, которая, как мне кажется, решит проблему команд, работающих со сложной иерархией тестов.

Суть проблемы:
Мы используем группировку тест-кейсов по кастомным полям (например, Feature → Story → Section). Это удобно, но сталкиваемся с жестким ограничением: для корректного отображения один тест-кейс может иметь только одно значение в каждом поле, а значит — только один «путь» в дереве. Иначе происходит ненужное дублирование папок, ниже поясню проблему подробнее на примере.

Пример:
У нас есть тест, который проверяет общую логику для функционала Х.
Логически он должен отображаться в двух разных ветках дерева, так как относится к разным бизнес-процессам, например:
Функционал 1 → Папка функционала 1 → Подпапка функционала 1
Функционал 2 → Папка функционала 2 → Подпапка функционала 2

Сейчас мы не можем этого сделать, не дублируя тест-кейс физически. Если мы укажем для одного теста Feature="Функционал 1", Story="Папка функционала 1","Папка функционала 2", Section(либо Suite)="Подпапка функционала 1","Подпапка функционала 2", тест появится не только в нужной ветке, но и создаст "мусорные" пути (из-за комбинации полей, т.е в Функционале 1 появятся и нужная нам "Папка функционала 1", и ненужная "Папка функционала 2").

Предложение:
Было бы идеально, если бы у тест-кейса была возможность задавать не просто значения для каждого уровня иерархии, а готовые "пути".
Например, в карточке тест-кейса добавить поле "Прямой путь" или "Дополнительное размещение", где можно было бы перечислить конкретные ветки, в которых он должен отображаться, скажем:
1) Функционал 1 → Папка функционала 1 → Подпапка функционала 1
2) Функционал 2 → Папка функционала 2 → Подпапка функционала 2

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

Почему это важно
Удобство навигации: Тестировщик, заходя в папку конкретного функционала, видит все связанные с ним тесты (включая общие/юнит-тесты), не переключаясь между разделами.
Отсутствие дублирования: Мы храним одну сущность, но она отображается во множестве контекстов, что упрощает поддержку базы знаний.
Чистота структуры: Позволяет избежать появления "пустых" или "мусорных" папок, которые возникают сейчас из-за смешивания разных комбинаций признаков.

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