I think it wold depend more on how you sell the n platform to the world. Instead of “yet another framework formally known as Meteor”, it could be known as “Market changing new framework from the same people who developed the highly successful Meteor.js”
I love to learn from past experiences of other people and companies. It always comes to my mind the bold actions Steve Jobs took at Apple that eventually saved his company. Hasn’t he moved to Macintosh away from highly successful Apple ][, Apple would be gone by now.
Mac launching was exactly that… “Market changing new computer (which back then was basically a framework) from the same people who developed the highly successful Apple ][”
Die hard users will stay for as long as the fibers version is maintained and keep evolving, just like the Apple ][ community did for years after the Mac.
Apple kept the Apple ][ for years and even launched the Apple III and Apple ][GS (which I bought). Amazingly, even today there is hardware and software being developed for the Apple ][ line… like SD card drives an so on… But, of course, it is a very niche market… Not the one we want for Meteor…
Meteor initially was driven by investments to build a platform. The landscape back then was very different than today, so meteor team had to develop a lot of tools and things from scratch and developed some great innovations back then. One such novelity was “real-time”-data as default and isomorphic code (That is still kind of unique to meteor). Consider what meteor had to invent back then: bundler, frontend-library (spark, blaze), datalayer (DDP), db-access, cordova-bundling, package manager, …
But the world moved on and better alternatives for the individual pieces came along, we have now a lot of frontend-frameworks, better datalayer abstractions, faster bundlers, etc.
Meteor partially had to open up to some of these technologies, because keeping up with the ecosystem around was no longer feasible. And demand from industry regarding scaling (both in code and performance) just got bigger and bigger.
The team around meteor had then the challenge of maintaining a lot of pieces and try to keep up with demand on the same time. Eventually, the original company kindof pivoted and focues only on the datalayer and eventually founded Apollo. While apollo (or graphql in general) was widely adopted outside of meteor, meteor itself never got the “magic graphql integration” we all hoped for. You could use meteor as an apollo server, but you did not need meteor for that and it added little benefit. So many either started to use more targeted tools like nextjs, apollo-client & server, etc. and went away from meteor or they stick to the initial core concept of meteor (maybe with a more modern ui-library).
Tiny eventually stepped in to maintain both the core meteor project and its hosting platform galaxy. I guess the motivation was to maintain it for the existing user base, evolving it where it makes sense, but without going too far away from its core. Given the complexity of the project, this is still a large area to maintain and room for improvement can be challenging.
Now regarding fiber and why this a big challenge:
As elaborated, many meteor users still use the “traditional” way of using meteor with mongo-collections, ddp, pub-sub, methods and tracker. Those code bases also often rely heavily on code-sharing, mainly in methods. Its these code-bases that are now affected by this fiber-deprecation. The path of migration might be easy in some projects, but it can get very hard in others (also given that probably many of those code bases are not in typescript). But there will be migration needed and @radekmie and others work hard on making this as painfree as possible.
Try to maintain fibers would also have been a possibility, but that would mean adding just another (very complicated!) piece to maintain for Tiny. And it would also mean that meteor would stay longer exactly where it is now and where it was for a long time. So I would take this breaking change as an opportunity for meteor to make a step in the future after a long time.
About creating some “meteor tosh” or “new meteor”: As initially mentioned, meteor had some big investments, it was not a community driven project nor something that evolved from another project (e.g. ruby on rails was abstracted out of Basecamp). It was built to create a disruptive new platform which eventually will get monetized.
Doing that again is not so easy nowadays and there are way too many alternatives (altough more fragmented) and meteor already proved whether such a platform can be successfull or not. So I doubt that we will see something like meteor any time soon.
But of course, everyone is invited to invision and start something similar! Even if its not a success, you will still learn from that!