This is a weird one to me. I really dislike the magical way Django does this and I'm glad Ecto doesn't. It also allows you to have separate Ecto structs representing different parts of a table in scenarios where that is desirable.
mix ash_postgres.generate_migrations --name name_of_my_migration
1. its opt-in, if you don't like it don't use it :)
2. we don't do magic migrations. We generate a regular ecto migration from your resource changes. So you can use it as a starting point and hand edit it (and often you should or even must as we can't do things like generating data migrations).
3. you don't have to map your resources one-to-one with tables. We support multiple resources being sourced from the same table, and turning on and off migration generation per resource. It's very common to have an Ash resource backed by a postgres view, or two ash resources backed by the same table. The migration generator merges resource definitions together to create "the strictest table definition that supports both resources". You can also remap field names. So at the end of the day, you can have your cake and eat it too on that front.
Currently it's true (for me) that writing the migration is copy pasting the fields from the ecto schemas and modifying them because the dsl is "almost the same but not totally".
I'm not sure that the Django approach would make sense in Ecto anyway because Ecto schemas are explicitly _not_ "models". The function of a Django/Rails "model" is divided between different concepts like schemas, Ecto.Query, Ecto.Changeset, the Repo etc.