My team did a migration changing a single column from binary(20) to varbinary(32) and found that rows modified during the migration sometimes got incorrect values in the new table. The values had trailing zero bytes stripped.
For example, if the column has X'6262a865515639288eb9611364bf50ad8489fe00' in it, the alter table command will keep that last byte, so that afterwards we have a value of length 20 in the varbinary(32) column. But if that same value is inserted during migration, so that gh-ost has to convert it, it's inserted as a value of length 19.
It looks like a variation on issue #909. The column in our example was not a primary key; that's probably why the fix in #915 did not save us.