This originates from CLX-630.
Let's take S3 Storage engine, and set it up in way that's used when both master and slave are pointed at the same S3 bucket (the specific option we're interested in is the s3_replicate_alter_as_create_select=1.
Then, if the master runs DROP TABLE tbl when it hasn't yet discovered the existence of table tbl, it will successfully drop the table, but the binlog will get DROP TABLE tbl instead of DROP TABLE IF EXISTS tbl. The table tbl will be gone when the slave executes the statement, which will cause it to stop with an error.
MTR testcase to demonstrate it:
This will show something like:
which is incorrect, it should be DROP TABLE IF EXISTS `t1`.
The slave will not fail because it had "seen" the table t1 before. If we had three nodes (one to create the table, then master->slave to run the testcase), we would get a replication failure.