autoincrement% settings you mentioned take care of
AUTO_INCREMENT values, but do not handle other
UNIQUE KEYs. Keep in mind that if a dup key error occurs, replication is stopped until a human intervenes.
Depending on how the code (router, proxy, etc) picks which Master to write to, you may have the "critical read" problem. This is where, say, someone posts something, then goes to another web page and expects to see the results of it. But the read goes to another machine and the results have not [yet] arrived because of replication delay.
Automatic failover is a big challenge. It is probably best left to be manual. If the network dies, you could have the "split brain" problem. In this case it is unsafe to failover because machine can't see the other. If they both blindly thing the other is dead, and take control, you could get data conflicts that are 'impossible' to fix.
Some of the issues are avoided by designating one of the Master as active and having the other be
After all, every write to a Master is also performed on every Slave (including the other Master in a dual-Master setup). That is, there is essentially no "write scaling" by having dual-Master. There is some "read scaling".
What is your goal of picking M-M? Scaling? HA? Disaster protection? Facilitate certain schema changes? Other? Are the two Masters located next to each other? On the same power source?
One of my points is that M-M provides limited benefits. And you may have to do other things to really achieve them. (Separate data centers, careful routing of queries to servers, etc.)
A number of the issues are lessened if you go to one of the "cluster solutions" (Galera or Group Replication). They require 3 servers, preferably in 3 geographic locations. But they handle split brain, automatic failover, and some other issues.