I have *really* enjoyed reading this thread. Any further updates to share? 
Um, since you've asked: The major contribution I am making is the new Disk Doctor, and the "third leg" of the feature set (1. Examine the volume to gather information for recovery, 2. Recover data from the volume, 3. Repair the volume) has finally taken shape.
At the moment I am tinkering with the repair process, and this is slow going. Part of the challenge is in figuring out how to deal with damage. The current plan is, to keep things simple for a first test release, to restore the volume to full working condition. This approach has side-effects, because it may mean deleting corrupted files, links and drawers from the volume altogether. Note that the affected data still remains on the volume, it's just that you can no longer access it once the repair process has concluded. Due to how the new Disk Doctor works, you will still be able to recover the data deleted by the repair process from the volume later if you change your mind.
Another challenge here is to find real world examples of damaged volumes which the recovery/repair operation can be tested with. Disk Doctor can simulate media damage as part of its test rig, but there's nothing like the real thing.
Because repairing the volume is already sufficiently complicated as it is, I made a decision on how to deal with DCFS (directory cache mode) volumes. For simplicity, the repair process will convert them to the respective international mode OFS/FFS format. This can be done without loss of data and is almost instant. It saves the time to rebuild all the affected directory caches, which for DCFS volumes easily takes up 50% of the total repair time.
Other repair tools left the job of rebuilding the directory cache and the block allocation information to the file system validator, which was never a popular choice. It always took too long, you never knew when it was finished, and if the repairs were insufficient the validation process could get stuck, even crash. The new Disk Doctor will, if repairs are possible, always leave the volume in a proper, validated state.
Disk Doctor aside, I have backported a few more shell commands to Workbench 3.1.4 in the hope that they may prove useful. This includes the "Sort" command, for example, which is interesting because it does not use the same sorting algorithm as the current Workbench 3.1.4 version (which is essentially an implementation of Quicksort, performed on a list).
Fun fact (for those who are into algorithms and not easily bored): the original Workbench 1.x "Sort" command would read a file one line at a time and then stuck that line into a binary tree, making no attempt to balance the tree. The sort operation then involved walking through the tree "in-order". Whatever could go wrong?
The backported "Sort" command brings back the binary tree idea, this time using the same algorithm which the ASL file requester and the Workbench use to keep a list sorted at all times, and in real time while it is being filled with data (without using recursion). In my tests I found that the new algorithm made the "Sort" command twice as fast.
