I would not over-read into that doc. In practice, the only missing stuff are extreme edge cases of the type that is actually not consistent between other implementations of bash.
In practice it works great. I haven't seen a failed command in a while
The big difference is how the microvm is utilized. Lambda reserves the entire VM to handle a request end to end. Fluid can use a VM for multiple concurrent requests. Since most workloads are often idle waiting for IO, this ends up being much more efficient.
Part 2 is that you can also use an actual server if your workloads happens to be predictable (or is partly predictable). That gives you better cost efficiency for that part of the workload
We're embracing copy-and-paste with the product rather than increasing abstraction. The tool provides the HTML or React code for building the generated UI. The way you actually use it, is by copy-pasting it into your app. From that moment on your workflow and specially debugging workflow is exactly as before. The tool just writes the first 100 lines of code to get you started with a great UI.
New generations are behind a waitlist, but you can see what the service does on the explore page (and bottom of homepage linked above) https://v0.dev/explore
Counter anecdote: As a Google engineer it always seemed like Edge implemented the sparsest possible version of the web platform to make major Google products work–and literally nothing else. That works to launch the browser, but then basically any product change runs a chance to no longer fall into that sparse subset and break in a browser. If Edge had implemented a more robust set of features, it would have massively improved compatibility down the road.