The motivation here is entirely to make fixing T1191 manageable, which is purely a support issue (lots of users hit issues with 4-byte characters in commit messages right now, in particular, which is a fairly serious error with no real workaround).

T1191 is scary since it involves a lot of schema changes. Roughly, we need to change every utf8 column to a utf8mb4 column.

A "shorter" path to solving T1191 is to add a huge migration which just swaps every table to the "best" character set and collation. This is roughly what we did to move to utf8 in the first place. However:

• This would be a huge amount of mandatory downtime for all installs as we swap almost every table's collations.
• If MySQL doesn't support utf8mb4 at the time we run the migration, we'll pick "binary", and there'd be no way for installs to upgrade later.
• There's a ton of room for human error, and we have far more tables now than we did the first time around.
• We got this wrong the first time around, although this wasn't clear at the time.

So this is a more supportable approach: build visual tools so users can understand/screenshot issues and to help catch human errors, make the migration independent of mainline schema changes so installs don't have to do it (at least, not all at once, for now) and so it can be reversed or upgraded later, allow the migration to apply partially, and give us tools to fix issues and make similar changes in the future.