But all the tooling we built for that multi-million LOC migration is open source, and available to everyone as part of the core SDK (https://dart.dev/null-safety/migration-guide#migration-tool). It's sophisticated, migrates much code automatically, and provides a visual editor to help make decisions about other code. That should be evidence at least that we care about migration.
Every ecosystem goes through migrations at some point (Objective-C to Swift, Java to Kotlin, Win32 to UWP, etc.) Flutter isn't immune to that risk, but I don't think it's particular to Flutter either.
At least some of your million dev userbase comprises of consultancy shops, contributing in part to your popularity by building products for their clients, but also making a buck with low effort on the underlying tech. They end up stitching codebases using unusual practices to meet deadlines that often blow up when a migration is upon them.
Angular had a migration tool called ngUpgrade that was painful in the wild.
All I'm saying is, these tradeoffs have now surfaced and crystallized.
Most of the anxiety and concern isn't from the Flutter project itself so I wholly empathize, but from Google's history in the dev space. Virtually anyone who had an AngularJS codebase knows what it means to depend on a Google OSS product that Google uses internally.
> There are many millions of lines of code written that power everything from Ads to our internal CRM system. Google wouldn't be better off if we had to throw all that code away and start over.
IIRC, when the AngularJS team came out with a brand new JS framework and called it "Angular", I believe the team explained how they automated migration of most of Google's "millions of lines" of complex internal codebase from AngularJS to Angular in a relatively short time, thanks to Google's internal infrastructure and tooling.
You could do dependency analysis, build ASTs across projects, at "Google scale", and have special tooling, transpilers, compilers to migrate code across Ads and verticals in a fortnight. Google has the talent, tools, cash to take such grand measures and come to conferences to showcase how they did it.
So the several million devs using Flutter are still undertaking a risk if Google deems targeting each new iOS version UX is too expensive, freezes contributions from internal devs, and starts internally migrating codebases to native with some shiny, new internal tooling.
EDIT: If such a scenario does come to pass internally, I think the Flutter community would very much appreciate project leaders being upfront about it.