Slave loses traditional master coordinates immediately on CHANGE MASTER TO MASTER_USE_GTID = 1

Possibly it currently works by design, and then it's more of a feature request than a bug report

As soon as we execute CHANGE MASTER TO MASTER_USE_GTID = 1 on a slave which had some master position, the master coordinates get reset.
It's understandably that the slave does not use old coordinates if it's configured to use GTID instead, but it seems dangerous to forget them before it even connected to the master and received the new (GTID-based position). For example, a user could issue the CHANGE by mistake, and immediately, before starting the slave, set MASTER_USE_GTID back to 0; but the position is already lost, and further attempt to start slave will cause data inconsistency and replication failure. Or, it might happen that the master does not support GTID, so the slave won't start. It produces very comprehensive error message, but it's quite difficult to fix the problem because the previous position is already forgotten.

Test case:

--source include/master-slave.inc

CREATE TABLE t1 (i int);

--sync_slave_with_master

--source include/stop_slave.inc

CHANGE MASTER TO MASTER_USE_GTID = 1;

CHANGE MASTER TO MASTER_USE_GTID = 0;

--source include/start_slave.inc

--connection master

INSERT INTO t1 VALUES (1);

--sync_slave_with_master

fails with

Last_Error	Error 'Table 't1' already exists' on query. Default database: 'test'. Query: 'CREATE TABLE t1 (i int)'

bzr version-info

revision-id: knielsen@knielsen-hq.org-20130503092729-gedp152b19k5wdnj

revno: 3626

branch-nick: 10.0-base