Because Quarterback Tools saved my butt so many times back in the days, I think this is pretty awesome news. This makes it possible to update it for use with newer versions of FFS (and who knows, maybe even PFS3AIO and whatever else).
I had a look at the "Quarterback Tools Deluxe" code, and for the most part the implementation is pretty solid. It covers the file system features introduced with Kickstart 3.0, namely the DCFS (directory cache mode, fast dir mode) format. It also handles both soft and hard links. I find this quite impressive, considering how little documentation existed for these features in 1992/1993. The repair functionality is limited to detecting issues with DCFS blocks (corruption). It does not repair them, though, and leaves the job to the file system validator.
One limitation which I could find concerns the block size. Up until Kickstart 2.0 a block was always the same size as a sector (e.g. 512 bytes). This was changed, by allowing a block to consist of several sectors (2, 4, 8, 16, 32, 64, or 128), up to 65536 bytes per block. The "Quarterback Tools Deluxe" programs which deal with direct disk access are unaware of the block size settings, they assume the block size and the sector size to be identical.
More serious is the handling of storage devices larger than 4 Gigabytes. All arithmetic operations on block numbers are performed using unsigned 32 bit integers. Any partition extending beyond or residing entirely beyond the 4 Gigabyte "barrier" cannot be safely modified, and reading from it may not retrieve the expected data.
So, from the looks of it, if you are already using the "Quarterback Tools Deluxe" tools, you should limit yourself to partition sizes smaller than 4 Gigabytes, with the partitions residing completely within the first 4 Gigabytes of a storage medium. I haven't checked (this is hard to figure out just by looking at the code), but it might just be possible that only the first 2 Gigabytes of a storage medium may be safe to use and repair after all.
From my experience, adapting an existing application to handle large storage devices can be really tricky. Translating the block numbers into 64 bit integer position values may be simple enough if the relevant code isn't scattered all over the place. You put a translation layer in place and that's it. The harder part is in dealing with the larger storage space: what worked with a 400 Megabyte partition no longer works so well with a 2 Gigabyte partition. Scalability issues pop up, e.g. linked lists are no longer adequate as the "workhorse" of managing the contents of a volume.