I also encounter this bug in production. It seems the counters stop updating when the connection is closed due to an inconsistent state.
For example:
2016-09-08 03:05:34 error : Slave 'db18' (10.10.44.38:3306) failed to execute session command.
2016-09-08 03:05:34 error : Failed to execute session command in 10.10.44.38:3306. Error was: 08S01 WSREP has not yet prepared node for application use
2016-09-08 03:05:34 error : Slave server 'db18': response differs from master's response. Closing connection due to inconsistent session state.
2016-09-08 03:05:35 notice : Server changed state: db18[10.10.44.38:3306]: lost_slave
2016-09-08 03:05:45 notice : Server changed state: db18[10.10.44.38:3306]: new_slave

To put this in context, the backend (db18) is part of a Galera server. It left the cluster because of a network split with the other nodes, then rejoined.
It should be easy to reproduce by adding an iptables rule that rejects the traffic from other nodes, but still accepts connections from MaxScale.

The active operation counters were not updated properly when multiple client packets were received. The counters were also incremented for each received packet instead of each started operation.

A good way to test this is to stream BLOB data via the C API and block the master connection mid-stream. This will cause an immediate mismatch in active connection and operation counts.