This is changing the syntax for setting up components, somewhat similar to the class API difference, but it’s still fundamentally the same library. It’s largely just moving functions store on the root object into the setup() function while using a more function-y tree-shaking supporting style.
It’d probably cause as much confusion as it helps.
Rust went through that around version 1 where a massive number of answers were updated to match new release and many got "this is not how it works anymore" comments.
That would be a huge problem. Right now they can just use the API they want and it will work for all the users regardless if they use objects, functions or classes.
That was overplayed in my opinion by Python 3.2 or so a large percentage of Python 2 code could be made Python 3 code with the addition of: from __future__ import print_function at the top of the file (provided your libraries also went to 3 that is) most people didn't use any of the stuff that was removed.
> “The proposed APIs are all new additions and can theoretically be introduced in a completely backwards compatible way.”
One thing they want to avoid is the whole Python 2 vs 3 distinction that went on forever. I’m not entirely sure these differences are that significant but having to merge in all of the data/computed/watch etc options into a single setup() function would require quite a bit of refactoring.