I don't agree with priority of this MDEV.

This requirement is every where. replication filtering is very used and sending all binlogs for just a a table or ignoring some big logs table on the master is a must do such events should not transit the network

Do you have something in mind that can enable like one time @ the biggest web shop in France to move a 100T DB that stop replicating when provisioning a new slave for changing a SAN?

We used multi source for each independent domain and fetch them in different replicated stream this enable to catch up after provisioning without blocking what is already replicated , but such solution is limited by the number of source as it will duplicate the network traffic for each source

If I understand Stephane correctly he wants to have binlog filtering on the binlog dump thread instead of the binary log writer thread.

This request has some significant advantages:

• nothing is lost in the binary log (for PiTR). This is the most important requirement!
• Sensitive data do not leave the Master (Slave could be a target for attacks in a less secure network zone). So we can avoid an intermediate slave just for filtering... Second most important requirement.
• Reduces network traffic
• Reduces relay log footprint on the slaves
• We can build different slave groups for filtering (for example some app1 Slaves, some app2 Slaves) and the configuration is only located on one place (Master)