That's actually the problem that this system addresses. Each change script has from and to versions, so it's dead simple to move from one schema version to another. So when you go to roll out to production, your build will notice that it needs to go from version 104 to 116, and will run the script 104-105, 105-106, etc. until the version number is where it belongs.
Basically, you can know with certainty that you can move from any numbered version to another by simply running the intervening scripts.
I understand that part, that's what I meant about it working in a linear fashion. What happens when two developers both start with schema 104 and develop in parallel? Which one of them becomes schema 105?
Ah. Since the scripts are under source control, it's simply a matter of resolving conflicts when you check in.
But then, since you'll generally have a continuous build is running on 5 minute intervals, it's pretty rare to have two independent schema changes in the same script.
Basically, you can know with certainty that you can move from any numbered version to another by simply running the intervening scripts.