RENAME temporary table may not find the target table on slave in RBR

In RBR operations on a tmp table are not binlogged, expect of currently
the only case of

DROP TEMPORARY TABLE IF EXISTS `tmp_table`

which is motivated by a possibility of `some_name`
existing on slave having arrived at slave at times before RBR mode has
been set.
[Since the existence is merely potential IF EXISTS is specified into
the above logged query].

Not being logged in RBR
RENAME TABLE `tmp_table_old` to `tmp_table_new`
can make master and slave inconsistent similarly to the above DROP
of potentially existing `tmp_table_old` on slave.
After RENAME on master `tmp_table_old` will no longer exist, and
should the "new" renamed table be deleted the following

DROP TEMPORARY TABLE IF EXISTS `tmp_table_new` /* renamed table */

would be replicated not to find the target table on the slave and thus an orphan
"old" table will remain there uncleaned forever.

A way to fix this issue requires either add
'IF EXISTS' keyword to 'RENAME' sql command or
provide an proper execution context within the replicated query so that
slave execution would simulate 'IF EXISTS'.

A multi-table RENAME (of list-of-table-pairs) needs some attention to prevent
renaming of a base "namesake" table instead of an aimed temporary one.
Perhaps RENAME TEMPORARY TABLE syntax could be introduced and used
to replicate the temporary table(s) RENAME separately (practically to extract the temporary table parts from a RENAME query to construct two Query-log-events).