This is actually InnoDB behaviour, as per this comment from the source:

-----------------------------------------------------------------------
/* The following assignment makes the transaction committed in memory
and makes its changes to data visible to other transactions.
NOTE that there is a small discrepancy from the strict formal
visibility rules here: a human user of the database can see
modifications made by another transaction T even before the necessary
log segment has been flushed to the disk. If the database happens to
crash before the flush, the user has seen modifications from T which
will never be a committed transaction. However, any transaction T2
which sees the modifications of the committing transaction T, and
which also itself makes modifications to the database, will get an lsn
larger than the committing transaction T. In the case where the log
flush fails, and T never gets committed, also T2 will never get
committed. */
-----------------------------------------------------------------------

I was able to repeat the same behaviour just with a standard InnoDB table, no
replication or GTID. Test case as follows, though it uses sleep and is thus
racy and may not behave the same on your machine:

-----------------------------------------------------------------------

1. rpl_mdev4694.test
   --source include/have_innodb.inc
   --source include/have_debug.inc

--connect(con1,localhost,root,,)

--connection default
CREATE TABLE t1 (a INT PRIMARY KEY, b INT) ENGINE=InnoDB;

INSERT INTO t1 VALUES (1, 1);
INSERT INTO t1 VALUES (2, 2);

--write_file $MYSQLTEST_VARDIR/tmp/mysqld.1.expect
wait
EOF

--connection con1
BEGIN;
INSERT INTO t1 VALUES (3,3);
DELETE FROM t1 WHERE a=1;
send COMMIT;

--connection default
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN;
SELECT * FROM t1 ORDER BY a;
SET SESSION debug_dbug="+d,dummy_disable_default_dbug_output";
SET SESSION debug_dbug="+d,crash_dispatch_command_before";
--error 2006,2013
SELECT 1;
--source include/wait_until_disconnected.inc

--append_file $MYSQLTEST_VARDIR/tmp/mysqld.1.expect
restart
EOF

--enable_reconnect
--source include/wait_until_connected_again.inc

SELECT * FROM t1 ORDER BY a;

--connection con1
--enable_reconnect
--error 0,2006,2013
reap;

--connection default
DROP TABLE t1;
-----------------------------------------------------------------------

You will need this .opt file:

-----------------------------------------------------------------------

1. rpl_mdev4694-master.opt
   --skip-stack-trace --skip-core-file
   -----------------------------------------------------------------------

And this patch:

-----------------------------------------------------------------------
=== modified file 'storage/xtradb/trx/trx0trx.c'
— storage/xtradb/trx/trx0trx.c 2013-06-06 15:51:28 +0000
+++ storage/xtradb/trx/trx0trx.c 2013-06-22 09:20:43 +0000
@@ -1200,7 +1200,7 @@ trx_commit_off_kernel(
ulint flush_log_at_trx_commit;

mutex_exit(&kernel_mutex);
-
+ os_thread_sleep(3000000);
if (trx->insert_undo != NULL) {

trx_undo_insert_cleanup(trx);

-----------------------------------------------------------------------

I get the following output:

-----------------------------------------------------------------------
CREATE TABLE t1 (a INT PRIMARY KEY, b INT) ENGINE=InnoDB;
INSERT INTO t1 VALUES (1, 1);
INSERT INTO t1 VALUES (2, 2);
BEGIN;
INSERT INTO t1 VALUES (3,3);
DELETE FROM t1 WHERE a=1;
COMMIT;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN;
SELECT * FROM t1 ORDER BY a;
a b
2 2
3 3
SET SESSION debug_dbug="+d,dummy_disable_default_dbug_output";
SET SESSION debug_dbug="+d,crash_dispatch_command_before";
SELECT 1;
Got one of the listed errors
SELECT * FROM t1 ORDER BY a;
a b
1 1
2 2
DROP TABLE t1;
main.rpl_mdev4694 'xtradb' [ pass ] 13829
-----------------------------------------------------------------------

So the transaction is visible before the crash, but gone after the crash.

So this seems to be intended InnoDB behaviour. Transactions seen just before a
crash may still be rolled back during crash recovery, if the crash happens in
the middle of the commit of said transactions.

I believe it will not cause any issues for GTID, as you also seem to
observe. The change to mysql.gtid_slave_pos will be recovered or rolled back
together with the replicated transaction during InnoDB crash recovery, so the
result will be consistent and correct irrespectively of visibility before the
crash.

So I will mark this as "not a bug". But please re-open if you think there are
more things related to this to consider or investigate. I am quite happy that
you have reached this deep level of testing of the GTID stuff. So please
continue reporting anything that appears strange, even if this is not a bug,
the next one may well be.

Thank you, I suspected there was a catch in there somewhere, but it looked so weird that I just had to find out. I agree that it's not a bug, at least as long as we don't find a scenario where it actually causes any trouble.