Take for example a GetUserStatistics() call which provides a list of userids and the users last login date.
A client might be using this list to get statistics on system usage.
If you change the codebase to add the concept of a test user and add an isTestUser column to GetUserStatistics() you have broken the contract with your users.
You had an implicit contract based on shared understanding of the data.
Now of course to correctly determine user usage statistics you need to exclude the test users by checking the new column.
As a consumer it is what I care about.
When transforming the schema, you frequently have associated changes that you apply to transform the data from one form (in the 'before' schema) to another (in the 'after' schema). These transformations are code that can have bugs like any other.
In cases like these you can have data that is in the right format, but isn't correct, and can need a second change (to the data only) to correct it.
Is there not? Lets say that you're changing the data in your database/data structure from state X to state Y. This involves transforming the data in some tables/data structures from the old structure to the new.
Lets say that you do this and it's all fine, the upgrade goes great. But then you discover there's a problem with the data upgrade.
While you have transformed the data into the new format, it's not been done right. So you actually need a second data change to ensure that your data upgrade is semantically equivalent to the data that went before it, even though the data conforms to your new schema.
Would that not count as a bug in your data?