Interestingly, that's exactly what is going on internally at the moment with Dart code, as we migrate the Google ecosystem to sound null safety, which was introduced in Dart 2 and will be the only mode in Dart 3. Adding a feature like sound null safety to a codebase the size of Google's is a large undertaking. It also brings a ton of benefit, both to the language itself and code that has migrated, since we can now provide guarantees around nullability that are not available in most other languages.
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.
I suppose two issues are at play: centralized OSS project stewardship that alters direction every 3-5 years to meet evolving org goals, and people building consulting careers on top of OSS projects that are strongly aligned with org goals (extreme case for impacted users).
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.
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.