This is the same pattern as versioning, but with an extremely short sunset for the old version.
The main difference I see is that of focus here the focus is to migrate a database without downtime or excessive global locks, keeping multiple versions of the schema is a detail.
Things can have similarities without being the same. Also not being unique is not a moral failure.
I think I am failing to understand your stance.
Patterns are necessarily reductionist, like any sort of comparison of things that aren't 100% similar.
There is value in recognizing patterns. They're useful for comprehension and memory.
I guess we disagree on the reasonable interpretations of this sentence
Versioning is a concept where each version lives in non-intersecting time intervals.
This concept is completely focusing on the fact that your structures lifetimes must absolutely have non-empty intersections. It's close to the opposite.
Is it? Node.js publishes "Current", "LTS" and "Maintenance" versions, and there's always a reasonable time interval during which consumers typically upgrade from eg Maintenance to newer LTS or even Current. From the publishing side, that's very similar to "expand and contract", in temporarily expanding what's supported to include Current, and dropping support for oldest versions leaving Maintenance. It's continuous instead of ad hoc, and there are more than 2 versions involved, but the principle is basically the same (at least if you squint).
Though I guess if you're talking strictly about schema management strategies, then yeah, "versioning" might be very different from "expand contract", as you noted.