Bug #42237 Character ü (u with diaeresis) not replicated correctly when used in view name

Description:
My problem is that when the character 'ü' is used in a view name it gets replicated to the slave as 'ü'. When used in a table name it is replicated correctly.

This seems to be a mixup between latin1 and utf8. 

'ü' in latin1 is:
00C3;LATIN CAPITAL LETTER A WITH TILDE
00BC;VULGAR FRACTION ONE QUARTER;

0xC3BC is exactly "small u with diaeresis" in UTF8.

So apparently the ü somehow gets written as UTF8 and interpreted as latin1 at some point.

Examining the master binlog with mysqlbinlog confirms the UTF8/latin1 inconsistency. All character set variables are set to 0x08 (latin1), but "u with diaeresis" for the CREATE VIEW statement is represented as 0xC3BC in the master binlog, which is UTF8.  So, the problem seems to be on the master side, the information in the master binlog is inconsistent.

My charset environment looks like this:
mysql> SHOW VARIABLES LIKE 'character_set_%';
+--------------------------+----------------------------------------------------------+
| Variable_name            | Value                                                                 
+--------------------------+----------------------------------------------------------+
| character_set_client     | latin1                                                                 
| character_set_connection | latin1                                                                 
| character_set_database   | latin1                                                                 
| character_set_filesystem | binary                                                                 
| character_set_results    | latin1                                                                 
| character_set_server     | latin1                                                                 
| character_set_system     | utf8                                                                   

How to repeat:
1. Set up a database with replication and the charset environment above.
2. Create a table and then a view, using "u with diaeresis" as part of the view name.
3. Observe inconsistent information in the master binlog for the CREATE VIEW statement.

Thank you for the report.

Verified as described. Most likely duplicate of bug #32200, but I live it separate, so developers can decide.

test case

Attachment: rpl_bug42237.test (application/octet-stream, text), 231 bytes.

Character set settings are same on slave and master. Also please note table name is not corrupted:

stop slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
reset master;
reset slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
start slave;
show variables like '%char%';
Variable_name   Value
character_set_client    latin1
character_set_connection        latin1
character_set_database  latin1
character_set_filesystem        binary
character_set_results   latin1
character_set_server    latin1
character_set_system    utf8
character_sets_dir      /Users/apple/bzr/mysql-5.1/sql/share/charsets/
set names latin1;
create view `###### as select 1;
create table `######`(f1 int);
set names utf8;
show full tables;
Tables_in_test  Table_type
ütest   VIEW
ütest2  BASE TABLE
flush logs;
show variables like '%char%';
Variable_name   Value
character_set_client    latin1
character_set_connection        latin1
character_set_database  latin1
character_set_filesystem        binary
character_set_results   latin1
character_set_server    latin1
character_set_system    utf8
character_sets_dir      /Users/apple/bzr/mysql-5.1/sql/share/charsets/
set names utf8;
show full tables;
Tables_in_test  Table_type
ã¼test  VIEW
ütest2  BASE TABLE

So, looks like this is, indeed, a duplicate of bug #32200.

Why is this a duplicate of 32200? 

32200 Describes the SQL thread stopping, while this report is about inconsistency between master and slave.

I don't deny it is the same cause, but the symptoms seem different. The symptoms from 32200 might not reproduce on the latest versions.