The definitive source of truth is here: github.com/WebAssembly/...
My c++ host implementation is here: github.com/GordonSmith/...

Yes — the host (c++, Rust, Java, etc) typically embeds a WebAssembly runtime (such as Wasmtime, WAMR, Chicory, or V8), which allows it to load and invoke guest WebAssembly modules—compiled from any language—while keeping them safely contained within the sandbox.

I have tried to keep current with the component model ABI specification (but depends on who is asking!).

I do embeddings not at the edge, but at the client (even better for the use case) using llama.cpp (in webassembly), it downloads the bge-base-en-v1.5-gguf embedding model as needed as well as a pre-calculated vector db (small enough to be to be in memory).

Something like: github.com/microsoft/wa...

I feel your pain - but if you have worked in the cross-compiler world (developing for platform X on platform Y) you will recognise a lot of those pain points and appreciate the "why" it is painful... IMO there is a critical mass now and you only need to look at all the "where" places it can be run!

When you say "the other one", I assume you mean another wasm module? If so, one wasm module, can't load another. But a single host can load two wasm modules and resolve their "imports" between them.

Ok, I will bite - what issues with WASI preview 3?

I use spin + vitepress for such things. Here is a boilerplate repo: github.com/GordonSmith/... and generated site: vitepress.fermyon.app

Any word on data accelerators being replaced with Hyperlight and Wasm?
learn.microsoft.com/en-us/azure/...

You may get better stack info, if you enable DWARF?

Kotlin?

I use the VitePress doc generator and it uses TextMate grammars via Shikira (from memory).

It does doesn't it!
But there is one significant difference: Java / JVM has full access to the host machine by default, while WebAssembly has zero access to the host machine by default...

I would recommend taking a look at "spin" from fermyon: www.fermyon.com/spin

Ensure you using a fast host (wamr, wasmtime etc), then you do an AOT compile for that host.
The other trick in the bag is to use github.com/bytecodealli... which lets you pre-run your wasm module up to a defined point and snapshots at that point, ideal for pre-initializing runtimes etc.

Shamless plug - There is a vscode extension which wraps all this up into a notebook enivironment: marketplace.visualstudio.com/items?itemNa...

It also has an `export to html` option to host in a single page...

I think you are missing the "why" of the hype.
If you limit your world view to hosts that can already run JS/TS natively then you are correct.
But given WASM can also execute in so many places outside of browser engines and since Rust treats WASM as a first-class target, the hype train isn't over.