The only option is to work around it by creating a whole second BDB instance, doubling the overhead, doubling the development effort needed, and bloating the code. Oh, and then the client would have to rescan after even trivial "clean" crashes (maybe even on normal starts too, now that I think about it), because there would be no way to do transactions across both instances and so the code could never be sure that both databases were synchronized, even if both were marked clean.
This is not entirely true, to be honest. Splitting the environment would mean some extra code, but after recent cleanups, it would certainly not be too hard anymore. Wallets store information about which blockchain they last saw (since 0.3.21 iirc), and are effectively rescanned at startup when there is a mismatch already, and we don't really do transactions across database files.
The only reason that hasn't been done, is because it is not the final solution. We've had so much troubles with BDB, because we don't use it in a way it was intended for (big servers with power generators, managing large database files simultaneously being accessed by many processes, with all log files backed up regularly to tapes, and software upgrades being performed manually by a database administrator; in this setting, it is rock solid).
As I said, the only real solution - in my opinion - is moving away from BDB and use a key-value store format that guarantees consistency in a single file. As the wallet is loaded entirely in memory anyway, that shouldn't be hard at all. I've already worked on this for a while, but right now, there are more urgent problems, and we're all volunteers that need to choose what to spend time on.