I'm not sure what you're hoping to accomplish by your first request, or even exactly what steps you're executing. To me, if you're going to run two instances of ST simultaneously, it makes most sense to have them working on two different books. Trying to do half of one book in one instance and half of the same book in another instance, and combining them afterward, seems like more trouble than it's worth. You'd definitely want to combine them before the page formatting step, so the sizes could match up. But maybe I'm not understanding.
I used to process all the right-hand images in one instance, and all the left-hand images in another (run back-to-back rather than simultaneously), and combine them with scripts after the fact. I no longer do that, because the resulting output page sizes occasionally didn't match. I don't think a right/left split would work well with what you're proposing, because the additions would have to be interleaved, but that didn't seem like what you were proposing anyway.
Your suggestion for hotkeys seems reasonable.
I've been looking into adding an "apply to" dialog to the content selection step. I still intend to do that, but I've found another enhancement that I intend to try first.
The "split page" step seems to be designed for books that were scanned on flatbed scanners, but often seems to fail when it shouldn't on books that came from our type of DIY scanners. Often, I find, the split page filter will either mark an image as "single page (no split)" or will split the image at the outer edge of a page, with the page, gutter, and portion of facing page passing on to the subsequent filters as the "page". This seems to be the true source of many of the failures I notice in the content selection step: a bit of the gutter is tagged as content, which will (if not corrected) result in a dark line marring the final output. If I correctly split the page at the gutter, and identify the real page correctly, 9 times out of 10 the content selection step that failed before will correctly bracket the text I want.
My plan is to add a fourth option to the "split page" filter, to identify the input as coming from our DIY-style scanner. If this option is selected, I'll use the same quick-and-dirty algorithm I used in my YAPP page puller to do the page splitting, instead of the algorithms Scan Tailor currently employs. It's doing gray scales and downsampling and Hough transforms, and circles and arrows with a paragraph on the back of each one to identify pages, which would be find if it wasn't failing as often as it does.
I think this will result in more steps which don't require manual intervention, which is my goal with an application like this. I don't think it will take care of everything, so I still plan to implement an "apply to" on the content step.
I'll take a look at the possibility of adding hotkeys while I'm at it. I haven't used QT before, but I'm beginning to become familiar with it. I don't think they should be too difficult to add, but I'll know more in a day or two.