My impression is that you are asking for the impossible. The underlying misconception (which I know very well for suffering from it myself) is that a filesystem aims at keeping the on-disc metadata consistent and that tools like fsck are intended to rapair any inconsistencies happening nontheless.
This, I learned, is not true. The point of syncronous metadata writes, soft dependency metadata write re-ordering, logging/journaling/WAPBL and whatnot is _not_ to keep the on-disc metadata consistent. The sole point is to, under all adverse conditions, leave that metadata in a state that can be _put back_ into a consistent state (peferrably reflecting an in-memory state not too far back from the time of the crash) by fsck, on-mount journal replay or whatever. That difference becomes perfectly clear with journalling. After an unclean shutdown, the on-disc metadata need not be consistent. But the journal enables putting it back into a consistent state quite easily. So fsck is not aimed at and does not claim to be able to recover from random inconsistencies in the on-disc metadata. It is aimed at repairing those inconsistencies that can occur because a crash _given the metadata was written syncronously_. FreeBSD's background fsck, by the way, is aimed at reparing only those inconsistencies that can occur given the metadata was written with softep's re-ordering. Of course, keeping the on-disc metadata in a ``repairable'' state incurs a performance penalty. So you seem to be asking for the File System Holy Grail: a file system that is as fast as asyncronous metadata writes, yet able to survive any possible kind of unclean shutdown. Such a thing, to my knowledge, doesn't exist.
