That purging is what has a lot of operational complexity. And renaming a column. All the rest is zero-downtime in PG already.
We rarely drop columns due to this, but haven't found it to be a huge issue. If we need to, we'll wait until the last supported version that has the column in its schema is retired. Then we'll add an explicit "drop column" to our schema file for the next version.
In the simplest form, when you add a column to some schema, it should be materialized in the base schema and exposed via the migration view.
The problems start when you add and remove 20 columns because even though they are no longer visible in migration schemas, they take up space in the base schema
All I'm saying is that I don't think we need a full Turing-complete cannonball to hit the (relatively) small fly of no-downtime migrations.
Is it a silver-bullet? It's Turing-complete so high chances yes. But for me it has a high risk of causing a silver-poisoning.
Personally, I would stick with simpler solutions.
Add Xn+1: create new views without column. When no Xn clients remain: drop column from tables and drop schema Xn.
The point as I see it is to not break live client connections which expect the column to exist.
You can use views to make migrations that were previously tricky zero-downtime.
If that's not the case, then I mist've read the article wrong!
Edit: although when I think of it - if you want to eventually materialize old migration schemas into the base schema, you need to do the rename, too. Which is not zero-downtime because of new migration schemas that do the renaming automatically. Meaning changing views' definition, meaning lots of locking.
So, you still need maintenance windows to merge all the changes. Just not on every change. Otherwise the base schema will then eventually be completely out of sync and contain tons of old, unused columns.