A little update...
I've been working mostly on the decompiler, which is a real head game. But to take a break, I try to fill in missing pieces of functionality. I can save successfully to SCI1.0 view and pic formats, but today I got views in SCI 1.1 working (KQ6, SQ5, etc...). SCI 1.1 has a significantly different format for view resources, with a bunch of extra info that even scummvm doesn't know about (according to the source code that loads the views). That's not a problem when loading the views, but I needed to figure out what to put in that extra data when saving so that the game thinks it's a legit resource. I'm not claiming to have figured everything out, but I did finally succeed in modifying a SQ5 view, saving it to the resource package and have it appear in the game (replaced one of the ships with a Cylon raider):

As for the decompiler, it was "90% functional", which means it did a good job on 90% of the code, which in practice means it's only successful at producing a completely accurate decompiled full script in maybe 5-10% of the cases. I was using a kind of haphazard method for determining code branching/loop structures, which turns out not to be robust enough. So I'm taking a step back and developing a more rigorous method based on "real" decompiler theory.
When it's good enough, I plan on implementing a way to supply variable names and such via an .ini file. That way when you figure out what procedure #5 in script #32 actually does, you can put a meaning name for it in the .ini file and redo the decompilation, and it will put in the new name you supplied. Same for variable names, etc...