When a switch happen in a intensive write environment, there are few things to keep in mind
1- is anyone using root/super privileges at the time the switch is request? by passing the read-only, maxscale has the privilege to check the processlist and the super privileges as well if anyone is using it
2- At the moment you monitoring the GTID there could be a query that is performing and increase the gtid even if dont see it
3- As i reported already, it seems a strong approach is the best starting point: on the db server primary, all connections should be cut, and if you want to redirect to a slave you can do at maxscale level, no leave connection open just for select on the previous master. At the moment connection remain
in a very busy env, switch master:
1- apply read_only to the PRIMARY (Make all non-temporary tables read-only, with the exception for replication (slave) threads and users with the SUPER privilege )
2- KILL all connections on database related to application ( do twice ina row) -> keep in mind that you could also have connections come direct to the server. not using maxscale, and maxscale should be able to coop also with those!
3- check not new connections are getting open, include root or super/privileges one
4- take the position
5- check there are is no changing position anymore
6- go to the secondary that is going to be promoted and check if the position is the same,besure all the relay has been consumed.
7- at this ( let say 1 microsecond) time, no one is able to write anywhere anymore
8- deal with reset slave all on the new master
9- set the replication on old master and start slave
10- check all topology is in order
11- remove read_only on the new master and give it to maxscale
If you could share the exactly step maxscale does it will be simple, i am sure there is any check about super privileges and root, even maxscale is able to check. Even more,we know atm, maxscale does not kill any connections after read_only apply, we need to have a better way to perform the switch.

When performing a switchover, we could wait for the transaction to complete, but at the same time we should block new ones from starting. And if the long transaction takes time, we are actually freezing the master. This is what is commonly done with backup, when FTWRL is issued to freeze non transactional tables when taking the backup position.
So I would rather kill any running transaction, which will be rolled back. A properly written application should retry the transaction if we kill it the proper way. The truth is, rarely applications do retry transactions, because it's actually easier to err out But this is not our fault, isn't it.
Don't know how transaction replay works in 2.3 and newer, if that can be done transparently for the application I would go for it.

Rick