> latin1 as an encoding also results in broken Unicode support That actually depends on whether your application actually relies on collation behaviors for cas

> latin1 as an encoding also results in broken Unicode support That actually depends on whether your application actually relies on collation behaviors for case insensitivity or accent insensitivity of non-Latin characters. From experience I can tell you that some of the largest companies in the world actually store unicode in MySQL tables using latin1 character set! It's not ideal and it's conceptually very gross. But in practice it actually works completely fine for these companies, because the relevant collation logic is handled in the application and/or in ancillary services. Anyway, I agree with your overall point that MySQL should have changed the "utf8" alias to point to utf8mb4 much much earlier. Although I also understand the significant backwards-compatibility concerns (especially regarding logical dumps) which forced MySQL/Sun/Oracle to slow-walk this change.