Currently, when we flutter create -t module, we put a platform host project as .android and .ios in the flutter project.

However, the user is never expected to interact with that ephemeral, generated project. Moving forward, we can either

1. Keep the ephemeral .ios, .android folders
2. Remove those project and just let the platform host projects be in the flutter_tools. Since the consumers of those platform host projects are either flutter_tools or scripts such as include_flutter.groovy / xcode_backend.sh embed, the tools can automatically connect the dots.
3. Fully materialize those folders and expect users to potentially edit them and source control them as well

The disadvantage of 2 is potentially missing very legitimate reasons why users would want to modify those projects. For instance, a user, in the future, wants to flutter build aar a flutter module but also needs to do it with a specific minSdkVersion or a java version. Since there are no longer any gradle files in the flutter module directory, it's no longe possible.

The disadvantage of 3 is leaving more potentially confusing and messy things for users to wrangle with even though the users likely won't want to ever touch them. And once they're materialized, they become very difficult to upgrade if we modify those host projects for future necessities.

I'm currently leaning towards leaving everything as 1.

If we discover in the future that there is indeed no reason for users to modify them, we can still modify the tools such that they're ignored and migrate everything into the tools. Those directories are ephemeral and never source controlled anyway.

If we discover in the future that users do need to tweak them, the migration step is simply to rename .android, .ios to android, ios and source control them. Flutter tools can always look out for android/ios first and .android/.ios second.

If we go with 1, that directory definitely needs a README.md to prevent people from accidentally losing code such as in #28135