@feinstein @darshankawar is this correct? If this is correct this influces whether flavors should be used at all imho.
Is there any documentation about best practice about if flavors are "critical" or if environment switcher and specific crashlytics/analytics urls and filtering are sufficient?

@neiljaywarner there are situations where flavors are critical. Imagine a project that needs a Cloud Firestore data base for production and another for development, or as in my case, several whitelabel apps that share the same code, but only have different names and package ids, so we would need to configure FlutterFire to deal with all the 4 android apps that use that same project, and not only one Android app.

Unfortunately there aren't many official guidelines, although you can find lots of recommendations online, but here's one of the offcial docs

Well, do you see how this would be possible for my use case?

I have 6 different white label apps (and growing), that I want to share the same Firebase, so I can have all the Crashlytics and remote configs at the same place.

Also, I want them to have a separate environment for development and production.

This works fine right now, and that's a functionality that Firebase supports, I am not inventing anything new, Firebase allows me to connect as many Android apps to one project as I want, so why the CLI shouldn't support something that Firebase already supports?

Also, there are many production apps like this, should we try to see how to change them all? How about data migrations for all of them?

I think it's simpler to just change the CLI, and while it doesn't get fixed, we rollback the manual configuration tutorials.