Комментарии 2
Мало! Надо ещё больше кода! Надо написать отдельный фреймворк для генерации классов выпадающих списков!
Энтропия всё растет и наша вселенная коллапсирует все быстрее.
В целом подход выглядит лучше, чем отдельные Enum, но не знаю, зачем вам понадобилось строго типизировать label. Если оставить его string (что в целом разумно - там может быть что угодно с учетом локализации и спецсимволов), то не придется обратно конвертировать в enum тип. Будет достаточно typeof enumConfig.Person.type[number]['value'] как string union, и в коде непосредственно писать строки вроде status: 'WORKING'. Типизация будет строгой, зато меньше нормализации и преобразований, когнитивной нагрузки в целом оберток.
Еще если вы уж выкладываете код на TypeScript, можно было бы побольше поработать над читаемостью. Сейчас читается сложно из-за разнородного нейминга - где-то сущность выносится вперед EnumConfig, где-то в середине UniqEnum, где-то есть явное определение что это тип с помощью суффикса PersonType. Дженерики в качестве динамических переменных тоже с разным неймингом: где-то однобуквенные T и K, где-то без префикса Seen, где-то с префиксом TValue.
TS-код это тоже код, и стабильные паттерны нейминга улучшают читаемость, как в js коде, где давно уже сложились best practice. В TS-коде они тоже есть - вот пример моего стиля, можно прогнать через LLM и спросить "почему именно так", ну либо сформировать свои паттерны. Такой вот лайт-код-ревью, надеюсь будет полезным)

Рефакторинг выпадающих списков: от enum к конфигу-константе