Назови темы по разному. Но вообще вряд ли тебе это реально нужно. Как ты планируешь это заставить работать?

Я загружу твой сайт, а потом изменю размер окна и что проийзойдёт?

Лучше используй относительные размеры или медиа выражения в стилях, а themekit просто собирает токены

вот что произойдет:

—headline-h1-fontSize: 32px;
@media (...) {
 —headline-h1-fontSize: 48px;  
}

Почему ты хочешь делать это в токенах, а не в стилях страницы?

потому что стили из токенов собираются

Я имею в виду темы. Почему тебе для этого нужен themekit? Ты мог бы делать так

.page__title {
font-size: var(--headline-h1-fontSize-m);
}

@media (...) {
.page__title {
font-size: var(--headline-h1-fontSize-xl);
}
}

затем чтобы вручную это не делать

Что именно?

есть компонент, стили которого не меняются:

.headline_size_xl {
 font-size: var(—headline-size-xxl-fontSize);
}

а вот переменную —headline-size-xxl-fontSize надо менять через медиа-запросы. При этом сама переменная из токенов

сегодня m, xl, завтра 3, 5 вариаций, а может один

платформы в themekite как раз это и позволяют делать. Ну и сама идея с уровнями переопределения

Это значит, что ты хочешь вынести логику стилизации компонента за пределы его описания.

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

Прямо сейчас ты мог бы создать темы с разными размерами и применять их в зависимости от размеров. Например Theme_size_m.

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

Скорее всего ты можешь использовать node api тула и генерировать такой код

нет, речь про платформы и уровни переопределения, которые и так есть. Вопрос про возможность их кастомизации.

Как я понимаю, платформы не для динамического изменения стилей. А переопределять ты можешь сам. Темы - это просто контейнеры с переменными. В их простоте большая сила

Мы ресечим переход на css-in-js или css-modules, так что в конечном итоге откажемся от classname

Я кстати проверял css модули, кажется что трудностей с этим нет.
Классы можно пробрасывать через контексты, а токены использовать глобальные, но если нужна уникальность, использовать префиксы на стадии сборки. Я думаю что модули намного проще, удобнее и привычнее чем css in js, Андрей Ситник придерживается такого же мнения, думаю мнение человека с такой экспертизой стоит учитывать. Решил это озвучить тут, что бы попытаться убедить в том что нам всем стоит использовать модули

css-modules или css-in-js в первую очередь закрывает проблему контракта между версткой и стилями, тебе не нужно два раза описывать классы и проверять, а используется ли этот селектор где-то ещё

Да, отличные технологии

А как у css-modules с уровнями переопределения? Если нужно доопределить, библиотечный компонент?

Для этого нужно использовать контекст элемента.

<ButtonTextContext.Provider value={{className: myCSSModuleValue}}>
  <Button>ClickMe</Button>
</ButtonTextContext.Provider>

Всё очень просто и расширяемо. Можно для этого писать свои обёртки. Надеюсь yandex-ui предпочтёт модули css in js решению.