Question on turning on GTID for MySQL master and slaves

I came across the interesting article by Facebook's Engineering team where they were able to deploy GTID in MySQL at a large scale : http://ift.tt/1FCYOEJ

Their idea to enable GTID is to keep GTID off on the master, and on on all the slaves, and then later promote one of the slaves as the new master and then turning on GTID on the original master :

"We worked around this problem in fb-mysql by relaxing the constraint that gtid_mode must match between master and replicas. We permit a gtid_mode=ON replica to have a gtid_mode=OFF master, and we suppress assignment of GTIDs to transactions on servers with read_only=ON (i.e., replicas). This permits a high-availability deployment strategy as follows, for each replica set:

1. On each replica, one at a time, restart MySQL to enable gtid_mode. Afterward, we are in a state where every replica has gtid_mode=ON, but the master still has gtid_mode=OFF.


2. Perform a master promotion as normal, repointing the replicas and original master to a new master. The original master's replication will intentionally break when started, since it still has gtid_mode=OFF.


3. Restart the original master to enable gtid_mode. It will now be able to replicate from the new master, and the entire replica set now has gtid_mode=ON. "

From what I understand about GTID in 5.6, either all the machines in your cluster need to have GTID on, or they need to have GTID off. So is Facebook able to have a GTID-ON master and GTID-OFF slaves because they have specially modified their MySQL to do so? This would otherwise not be supported under a normal MySQL 5.6 release right?

Thank you