True, but I wouldn’t be too concerned about SQL becoming opinionated, as the main goal is foreign language integration, which lend itself to prioritize building tooling that can be used in a provided mix task or other libraries hooking into said API.
Which means that we would have to look at migrations from a new angle, that is further away from what Ecto does today, but closer to Ash. Before we can do this we need to address the fundamental questions, why do we have database migrations, what do they solve, and what would they look like if they where native to the application language, or in the SQL specification itself.
I’m looking forward to this exercise.
