I don't think it's a bad idea, but having looked into this sort of thing pretty deeply, I do think it's a "now you have two problems" idea when started by centering an ideal VM.
Foundational software is very slippery stuff - it's analogous to having a yeast culture. Before the software was there we had machine language and the specific hardware, but gradually we built a stack of compiler tech, common protocols, etc. And from there we went and started targeting the end of further abstracting it, making it perfectly portable and so forth, but that's like trying to engineer a perfect yeast: while some might get a better benchmark on some metric, the overall metric is a pass/fail: "Can I bake bread with this?"
Of course, a lot of people give up along the way and buy something off the shelf, because they want bread now. And that's fine - they're eating off it, and the world keeps turning.
But if you do try, you can "do more with less" by carefully limiting the kinds of computation and I/O you're doing and describing that as a protocol, then developing software around the protocol. At that point, the software's specification has an insulation barrier from its dependencies, and you don't necessarily care about the whole of the dependency because you've selected a subset whose specific features and codepaths can be vetted in more depth.
And the odd thing about this is that it's the kind of thing that, at its outset, doesn't lead towards complexity, because you intentionally started with a system that does less than its dependent parts: but once you have that, you can knock out and replace the dependencies to "do one thing well," ship of Theseus style. At that point it can become larger again, and evolve. And that's roughly how we ended up with the giant soup of stuff that is "Web tech". At every point along the way, it did bake bread. But when it was first specified, it hardly did anything at all: it bundled "download remote files, present files as documents".
Foundational software is very slippery stuff - it's analogous to having a yeast culture. Before the software was there we had machine language and the specific hardware, but gradually we built a stack of compiler tech, common protocols, etc. And from there we went and started targeting the end of further abstracting it, making it perfectly portable and so forth, but that's like trying to engineer a perfect yeast: while some might get a better benchmark on some metric, the overall metric is a pass/fail: "Can I bake bread with this?"
Of course, a lot of people give up along the way and buy something off the shelf, because they want bread now. And that's fine - they're eating off it, and the world keeps turning.
But if you do try, you can "do more with less" by carefully limiting the kinds of computation and I/O you're doing and describing that as a protocol, then developing software around the protocol. At that point, the software's specification has an insulation barrier from its dependencies, and you don't necessarily care about the whole of the dependency because you've selected a subset whose specific features and codepaths can be vetted in more depth.
And the odd thing about this is that it's the kind of thing that, at its outset, doesn't lead towards complexity, because you intentionally started with a system that does less than its dependent parts: but once you have that, you can knock out and replace the dependencies to "do one thing well," ship of Theseus style. At that point it can become larger again, and evolve. And that's roughly how we ended up with the giant soup of stuff that is "Web tech". At every point along the way, it did bake bread. But when it was first specified, it hardly did anything at all: it bundled "download remote files, present files as documents".