If you find yourself needing a replication solution beyond hot standby; it's possible that PostgreSQL isn't the right tool for the job.
The reason most replication systems sit outside of PostgreSQL are there are many different use cases for replication and no one method is going to get it right enough to complicate the core code. There are efforts underway to create a common structure to base replication on so that projects like Bucardo, Slony and Londiste can more easily and reliably plug into the core database engine for replication.
It's even harder to maintain than multi-master. You know what can fail in multi-master and how to check it - 99% of cases is just one of the nodes stopping accepting the replication stream for some reason. You can check that easily, because you see secs_behind > 0 on the slave status - everything else ends up in the error log.
With NDB, the situation is much harder. You've got 3 types of nodes that can fail, you don't easily see if one of them failed (I had situations where every node was "connected", both data nodes were "live", but the manager (or was it frontend...) decided they're out of sync and cannot deal with them at all). Effectively you've got a network of independent nodes which can fail and not output any error - it's another node that shows you only the effect of such failure. I could not find any way to reliably monitor the cluster status and there are not nearly enough information on the web to solve the problems on your own. #mysql-ndb is great, but the people there can give you a patch to your database "to try if it fixes the problem" - problem that cannot be easily reproduced and causes the DB to stop working under a high load in the middle of the day - exactly when I need to DB to stay up.
Multi-master was a lot less painful.
I think MySQL's swappable storage engines make building replication a tad easier. Actually, I have no idea.