Those projects all had a unique and very successful take on the problem they were solving, though.
The problem with creating a new OS is getting people to write apps. It's not really justifiable if your new OS doesn't take a very different approach to how apps are written and yield much better results as a consequence. If you build a new OS and rely too heavily on emulated Linux apps, then what is your value proposition? You're effectively admitting defeat up front by saying there's no real reason to write a native app; that running Linux apps is good enough.
With Fuschia this problem is especially apparent because it's not really obvious from reading the docs what its value prop really is, or how the UX of a native app differs from any other platform. Successful operating systems don't normally have this problem. You could argue that Linux was an exception, but there the value prop was being an open source PC UNIX and that price/compatibility point was enough. Other platforms though, like macOS or Android, needed to have a very clear offering up front to get developers to care, as well as a large library of first party apps.
Your points don't jive with the success of ChromeOS. It doesn't have "native" apps, and runs Android and Linux applications via VMs. No one writing applications targets ChromeOS as far as I know. They target chrome, steam, or Android. People don't write applications for OS anymore, they write applications for platforms which can be abstracted and ported to different OS.
Good point, but, you can argue that ChromeOS isn't actually the OS in that case. Linux and HTML5 are. ChromeOS is more or less a detail of the hardware that matters to admins who want/need total control and entirely cattle-like devices (the unique value prop).
I agree with you though that people are mostly writing to abstraction layers. That's where the action is, which is why it's curious that Fuschia's approach isn't clearly a ChromeOS style "portable abstraction layer + shell to invoke abstracted apps". They use Dart and Flutter for the UI so in some ways it is, but then they have the whole component model and Fuschia specific APIs.
Fuchsia isn't necessarily targeting end users or application developers. Fuchsia exists to make products easier to build and maintain. Products are responsible for the app developer and end user experience.
The problem with creating a new OS is getting people to write apps. It's not really justifiable if your new OS doesn't take a very different approach to how apps are written and yield much better results as a consequence. If you build a new OS and rely too heavily on emulated Linux apps, then what is your value proposition? You're effectively admitting defeat up front by saying there's no real reason to write a native app; that running Linux apps is good enough.
With Fuschia this problem is especially apparent because it's not really obvious from reading the docs what its value prop really is, or how the UX of a native app differs from any other platform. Successful operating systems don't normally have this problem. You could argue that Linux was an exception, but there the value prop was being an open source PC UNIX and that price/compatibility point was enough. Other platforms though, like macOS or Android, needed to have a very clear offering up front to get developers to care, as well as a large library of first party apps.