Ну я опять же тебя отошлю к кордове в плане стилизации. А в плане лэйаутинга к бутстрапу.
Я искренне верю что можно сделать общий API. Несколько мне известно самая серьёзная проблема кроссплатформы веб-бейзд — перфоманс

Я процитирую тебе вопрос к тебе же из твиттера. Ты давно на бутсрапе писал? Я вот очень недавно. Честно тебе скажу, лейаутинг выглядит очень по-разному в компоузе и в бутстрапе. Виджеты выглядят очень по-разному. Одно к другому притянуть не получится. А Кордова все-таки довольно маргинальная штука. Как раз по той причине, что не получается все это склеить удачно.

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

Примерно как работают OpenAPI генераторы

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

Так да, можно. Я же про это с самого начала говорю. Но это не будет one code to rule them all.

Мне очень нравится как выглядит прототип компоуз фор веб. И мне не нужны там андроидные компоненты

Если это можно сделать отдельной библиотекой (а должно быть можно) - то это просто станет лэйаутингом для компоуза

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

И тогда можно дальше делать наборы компонентов, которые боее или менее на всех устройствах работают одинаково тем, кому это нужно.

Но я не уверен, что этим универсальным набором будут андроидные компоненты

Всё, договорились :)

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

Спасибо за разъяснения. Я потом уже пришел к этому выводу, когда изучил страницу примера. Получается я свой Стейт менеджер на бэке должен реализовывать и опрашивать все виджеты , чтобы какую то интерактивность организовать?

вы наверное не поняли, что значит "умеет транслироваться в жс"

fun main() {
    val button = document.getElementById("button")
    button.onClick = {
        document.alert("test")
    }
}

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

Допустим я хочу такую функциональность: селект лист со списком из трёх имён файлов и кнопку Загрузить. По кнопке сервер должен отдать выбранный файл. Первичный инит рендер я сделаю, а дальше мне нажатие кнопки надо отработать на бэке и посмотреть Стейт селект листа, чтобы выдать нужны файл. Интересует есть ли готовые инструменты для сбора информации от виджетов. Или я сразу должен в Котлин коде всю логику прописать и расширить ее смогу только переписав код фронта?

а в жс как бы вы это делали?

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

Готовых universal фреймворков для Kotlin нету, я пишу один (копирую реакт). Возможно compose когда-нибудь так делать будет, но вряд ли. Возможность "гидрации" сгенеренного на беке HTML надо сразу продумывать, потом сложнее будет ее сделать.

А ваш проект, над которым вы работаете, он какую модель будет реализовывать?