Drizzle is transactional by default.
Bad data? We don't insert it, we toss an error (and if we don't in some cases, it is a bug).
We purposely went after the issues in the MySQL gotchas list when we began (http://sql-info.de/mysql/).
Our DDL? Soon will be transactional. Our data dictionary is federated out to engines, so unlike MySQL in our system the engine owns the definition so you can't end up in a situation where the engine is off from the definition.
I wouldn't make the assumption that because we have a similar ancestor that we are the same at all. It would be like assuming Postgres and Ingres are the same (which they are most certainly not).
When I first started doing the rewrite I considered Postgres (and spoke to a number of the developers of it at the time). In the first year I went back and forth in my head on that decision. There would have been a lot of things that would have made PG a better starting point. By the time we reached 5.1 the MySQL codebase was junk. Postgres would have made for a good decision but there were three drawbacks.
1) Postgres is C and not C++. I find that I can write code in C++ nowadays much faster then I can in C (and it comes out just as fast, the C++ "is slow" is an archaic view).
2) Postgres is not designed to use threads. I prefer to work with threads over processes (and there is a lot of good and bad with both concepts).
3) Sun wouldn't have paid for it ;)
I wouldn't consider SQLite. It is neither type safe, not concurrent. It is a great database, but it doesn't solve any of my needs. I did think about Firebird for a bit, but while I know the MySQL and Postgres codebase, I don't know the Firebird code at all.