Regarding the Kotlin parts:
• Bundle sizes required for casual web usage will probably be an issue currently with Kotlin/Js and Kotlin/Wasm, depending on which libraries you use.
• SEO will be an issue with Compose Web (Canvas), but not with Compose HTML, which directly manipulates the DOM. Note that the latter has a different API for UI components compared to the other targets of Compose Multiplatform.
• Kotlin/Wasm and Compose Web (Canvas) are still at early stages, so you might want to prototype carefully what works well enough for you. (Though you'd want to carefully prototype anything as even legacy frameworks often do not live up to expectations.)
• Kotlin provides easy-and-safe-to-use concurrency even in single-threaded environments such as the browser (ignoring web workers), which should be sufficient for SEO-friendly DOM-based web applications with small bundle sizes.
Other than that:
• What makes you require multithreading instead of just concurrency in the above use case? (To me, that sound like a fat client approach with some heavy computations in the frontend. And that would smell like large bundles.)
• Going with something like Vue or Svelte instead of React seems reasonable in your case (cf.
The self-fulfilling prophecy of React and
The Market for Lemons - Infrequently Noted), but results in limited code sharing across frontends (such as mobile or desktop) when compared to Compose-based approaches.