MaxScale's binlogrouter:

MariaDB [(none)]> show slave status \G

 Slave_IO_State: Reconnecting after a failed primary event read

 Master_Host: x.y.z.w

 Master_User: maxscaleuser

 Master_Port: 3306

 Connect_Retry: 1

 Master_Log_File: mariadb_bin_log.000123

 Read_Master_Log_Pos: 123456789

Master_Log_File & Read_Master_Log_Pos refer to the local maxscale's coordinates while the standard MariadB behaviour would report the Master's binary log coordinates.

Apart from consistency, without such info is difficult to read the Master binlog events since neither SHOW BINLOG EVENTS nor mysqlbinlog support GTID.

Some considerations on where to report MaxScale's local coordinates:

 Master_Log_File: 	READ FILE	Primary

 Read_Master_Log_Pos: 	READ POS	Primary

 Relay_Log_File: 	EXEC FILE	Local/Replica

 Relay_Log_Pos: 	EXEC POS	Local/Replica

 Relay_Master_Log_File:	EXEC FILE	Primary		Note: Slave might be lagging

 Exec_Master_Log_Pos: 	EXEC FILE	Primary		Note: Slave might be lagging

 n/a:	 	WRIT'N FILE	Local/Replica	*** MISSING ***

 n/a: 		WRIT'N POS	Local/Replica	*** MISSING ***	

What's historically missing in the output is what is the position written in Local Relay log Coordinates
On a Slave where the Slave thread is stopped you will see a static (Relay_Log_File,Relay_Log_Pos) but the slave is most probably keep writing the relay log.

MaxScale does not execute but just read and write the Master events, so it's compatible with having only one set of "Relay" Coordinates.
In theory the right place to report maxscale write log coordinates would be in the missing fields.
If we have to keep the standard output then the second choice would be Relay_Log_File/Relay_Log_Pos (even if that's not really the exec position but rather the written position)