slave_transaction_retries < slave-parallel-threads quite risky

I encountered 11 instances of the following in a binlog group commit along with one other transaction on a different table.

UPDATE variable SET value='a:0:{}'

WHERE ( (name = 'rules_event_whitelist') )

the slave settings where:

(replication not in gtid mode)
slave_transaction_retries=10 (default)
slave-parallel-threads=20

master had binlog_commit_wait_count=20

as such the replication was stopped and the error was in the log:

150701  2:01:33 [ERROR] Slave worker thread retried transaction 10 time(s) in vain, giving up. Consider raising the value of the slave_transaction_retries variable.

150701  2:01:33 [ERROR] Slave SQL: Deadlock found when trying to get lock; try restarting transaction, Gtid 0-8-1270304033, Internal MariaDB error code: 1213

150701  2:01:33 [Warning] Slave: Connection was killed Error_code: 1927

150701  2:01:33 [Warning] Slave: Connection was killed Error_code: 1927

150701  2:01:33 [Warning] Slave: Deadlock found when trying to get lock; try restarting transaction Error_code: 1213

150701  2:01:33 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.010502' position 38545619

a) Stopping replication after slave_transaction_retries has been achieved puts me in a much worse state than continuing to try, so is there any case where slave_transaction_retries is useful (apart from catching a coding error)?

b) is slave_transaction_retries = slave-parallel-threads sufficient to resolve this in the mean time? or do i need to set this to factorial(slave-parallel-threads) ?

I read though MDEV-7882 and it looked different. Does anything else post 10.0.17 release change the handling of this situation?