When using slave_run_triggers_for_rbr on the slave, if there are triggers on the master table, any triggers on the slave will still not be executed. This is fine, given the assumption that the slave and master have the same schema and the triggers on the master has already executed and operations that would be executed by the triggers on the slave, thus avoiding the same operation being executed twice.
Although this makes sense in many cases, in other cases this is not so. In a situation when there are triggers on a table on both the master and the slave, but these are completely different triggers, by design, and you actually want both the triggers on the master and the slave to execute and the user knows hos to deal with this, you would want to enforce the trigger on the to execute, independent of the existance of a trigger on the master.
One use case for this is to allow for "asynchronous" triggers, so that triggers that takes has a rather high performance penalty can be executed on an asynchronous slave.
The suggested fix to this is not to break the existing restrictive mode, which in many cases makes sense, but to add a new mode to slave_run_triggers_for_rbr beyond, YES, NO and LOGGING. This could be called ENFORCE or something similar.

A suggested patch, based on MariaDB 10.4.8, is attached.