Davi Arnaut @ Twitter has created a few patches to make RBR status more visible. Can we get these included in MariaDB?
There are quite a few gems in the Twitter patches - perhaps a bigger review and a comprehensive cherrypick is in order!

https://github.com/twitter/mysql/commit/3a1e4b5682d994ccefc919a33d9ac7d2adc92705

Expose current RBR execution state in the SQL Thread state

The execution of row-based events in a replication slave is not
reflected in the SQL Thread state, making it rather difficult to
identify long-running events. For example, the execution of a large
row-by-row delete event is not immediately identifiable as the
replication SQL thread state for most of its duration stays as
"Reading event from the relay log".

This change adds two new states to the replication slave SQL thread
that are used to highlight the event that the SQL thread is executing
and, for row-based events, to indicate how many rows have been
applied. These will generally look like:

Executing Delete_rows event at position 100
Handling record 50 of 100 for a Delete_rows event

Additionally, the outermost state of a thread state is now saved and
restored when inner states are set, so that the overall information
of what the thread is doing is not lost.

https://github.com/twitter/mysql/commit/d9895b4410f744a231f789ec9d894dbe633e3b14

Slave should include the table name in its status while processing

RBR events.

When processing a row-based event, the SQL Thread state is updated to
reflect what type of event is being processed, but short of dumping the
event from the logs, there is currently no way to identify to which
table the event is being applied to.

In order to allow for easier identification of which table an event is
being applied to, this change extends the SQL Thread state to also
include the fully qualified name of the table associated with an event
being applied.