It would be easy to just say "yes, I got a bit carried away with the naming and my big future plans, but the community reaction made me realise perhaps it was not a great idea"
Insead he's like: "what? it was the plan all along :)"
We're all still learning how to work with the RFC documents. We want them to be an important tool for the community but initially, the response from the community was very low. Paradoxically this whole situation made the wider community aware of those RFC documents so hopefully it will go in a good direction. But that initial low response made us believe "oh we have time to sort out things like the phrasing". Turned out it was wrong.
The advice to change the names came from the community and it was a good one. It got support in the core team internal channels and got implemented.
That's a clue for where the Vue team's mind is regarding the current API. Compatibility to me reads like legacy. That's in contrast with the claims above that this is just a new optional API to serve a broader range of use cases.
The "production" build will ship with the stuff that particular project uses. That means both what they use in their codebase and what Vue uses internally to handle that code.
But there also has to be a way for Vue to understand what the user wants to be in the bundle. This is easier for the users who use the new syntax, where the individual features are explicitly imported.
Earlier today, there was a "Standard" build and a "Compatibility" build.
The "Standard" build excluded support for "data", "computed", "methods", "watch", "provide/inject", "mixins", "extends", and all lifecycle hooks.
In the updated document, the old "Compatibility" build became the "Standard" build, and the old "Standard" build became the "Lean" build.