This was clearly intended to eventually replace Android and ChromeOS. The layoffs are likely because someone high up freaked out about how many people were working on a very very long term strategic project.
I would guess dropping native Chrome is because it's a ton of work and they don't need it, at least not for a long time. They can use Flutter for embedded devices, and if they support Android they can just run Chrome for Android.
Back in ZIRP days, Google did. I was there and saw it firsthand. Were you? I know the initial team that started this. Very smart folks. But there was never a shred of future there. When they tried to convince me to join the team, there was no answer to my question of "who would use this and why?". Android compat would never happen without a vm or container (in which case all the fancy privilege control is useless since all the sensitive data is INSIDE the container that MUST act linux-like and not fancy-priviledge-separation-like). And nobody would rewrite all the apps of the world to fit the new paradigm, as seen by chrome dropping this target finally, and by the failure of much-better-sponsored windows phone OS. Given that even the team had no clear answer to what they were doing and why, yes, the conclusion is that they were permitted to do this just to keep them off market to competitors, and available should they be needed elsewhere at Google. This also explains why there were layoffs in the team once the free money ended, and it expains this article here too.
I think it would have been fine to just throw the Android runtime in a container. That wouldn't be useless - it was still a great opportunity to reinvent the kernel and the Linux driver model, and all of the other parts of the system.
I find the "staff retention" thing confusing. Sure, I understand talented people want some freedom and flexibility, but I don't think that having a team of 400+ people go crazy for years with no plan is the only way to retain. Why not let them go crazy for a while but then force them to downscope, pick a real need and solve it with their tech?
Or, why not make it more incubator-style? Instead of a team of 400, have 10 teams of 40 and give them a year to build something amazing, then turn only the top 1 or 2 into products and send the others back to the drawing board?
You worked at google. Would you say that serious top-down leadership with a vision existed in the age of Sundar? I spent time in ChromeOS and Android teams. Almost 8 years of time. The actual teams had some vision and plans, but there was NOTHING from above. So yes, it is quite believable to me. Imagine: fuchsia team wanted to fuck around for funsies. Nobody above stopped it. It is so google 2012+
VM-per-app has very real possibilities. You'd need some new logic for things like keyboard apps, but ...
I worked at Google (on the Chrome team) for years while Fuchsia was getting started.
Replacing Android and Chrome OS would have made so much sense, but they were definitely NOT trying to do that. I never understood why.
They had a great plan for an OS that lived in a complete vacuum, with absolutely no plan to gain adoption or transition any existing platform to it.
It was literally tech for the sake of tech, and it made no sense.
It's expected that this kind of strategy will yield nothing most of the time, but eventually you get a positive Black Swan.
Are you sure? In my experience people often say that project X isn't intended to replace project Y when it absolutely is, in order to avoid having to fight the people working on project Y.
An open source example of this is WASM. When it first appeared there were countless "wasm isn't intended to replace JavaScript" claims. Of course it 100% was (for a number of use cases anyway), but people had to say that to placate the JS fanatics.
It looks like Google potted ART to Fuchsia at one point.