After some time here is another post concerning MySQL. It is not as if I had not had anything to do with MySQL in the meantime, but most of it was mailing back and forth with their customer support (which is really quite good) to get some issues resolved we stumbled over in our MySQL 4.1 to 5.0 migration.
Before those were fixed we could not use MySQL 5 with our application, because there were some incompatible changes we could not work around.
One of them was the unsatisfactory precision when querying DECIMALs I wrote about earlier. This is fixed in 5.0.32-enterprise and the just released 5.0.33 community edition (see Bug #23260). In fact I was just about to write about the new release policy which I find somewhat strange (enterprise and community editions with the enterprise releases being faster than the community ones) when I noticed that a new community release had been made public the day before yesterday. If you like to know more about this whole "edition" thing, see the MySQL Performance Blog's post about where to get a recent MySQL version and also pay attention to the comments.
Another problem we noticed and reported to MySQL at the end of October was a changed behavior of InnoDB regarding rollbacks after lock-wait timeouts. MySQL 5 would only rollback last statement of a transaction if it ran into a lock-wait timeout. MySQL 4.1 instead rolled back the whole transaction. As we use a persistence framework which may automatically re-order a transaction's individual statements, this something that really bites us.
Fortunately MySQL agreed on providing a compatibility mode through a configuration option. Strangely this is not noted in the release notes of either 5.0.33 nor 5.0.32, however the relevant Bug #24200 contains the switch's name (innodb_rollback_on_timeout) which restores the old behavior.
So it seems we will be able to change to MySQL 5 finally.