That is my thinking.
I hope you are not proposing that, can you clarify this statement?
It might, but honestly, I don’t think so. I don’t think Fibers is holding Meteor back, we can still use async/await and Fibers, and frankly the larger community doesn’t know about Fibers in fact they don’t even know what is happening with Meteor in its entirety. I’d put my money on HMR, tree-shaking, NPM meteor client library, scaling, etc. And most importantly better documentation, marketing, stability and long-term support.
I think that there is a good chance Meteor 2.0 might be on Deno, that is to say, porting Meteor’s style of development and experience to Deno land. There is a reason why Ryan (author of Node) created Deno from scratch, at this stage of Node maturity, it is almost impossible, and would could argue to even desirable, to fundamentally change Node (adding sandboxing or removing package.json, changing the APIs, etc.) without breaking the entire ecosystem, so people are fine living with Node legacy and accepting the tradeoffs, I think the same can be said about Fibers and todays Meteor.