So now I have collected some feedback, let me expand a bit more (yeah, sorry, no update so far, unfortunately I've been kept busy by a few other commitments, like making sure you get the 1.0.1 update ASAP).
Edwards, as you know yourself not even the size or bounding rectangle of a sprite is stored in the level, only its position and orientation. This means I'd have to locate the SketchFighter app and interpret the various data files even for displaying them. I'd like to keep this little tool as simple as possible (not to mention that it could be broken if ever the internal data formats change). So a first release of this tool won't include this at any rate.
cheleball, Lars does take the editor seriously, it's just a bit low-level, down to the level details (i.e. backgrounds that have to be there in perfectly aligned squares); in fact he improved the auto-background tool recently ofr the next update. So there.
About this tool: I'll keep the command-line interface (and I intentionally worked so that it would deal gracefully with malformed input, I'm unfriendly enough to give only a command-line version already, better not make things worse by making the program mysteriously not work when there's a typo) and create a GUI version (they will share the actual, level-merging and modifying code), though don't expect anything really complex, probably a setup screen where you will be able to input the two files, set the options for each file (shift, rotation, which layers to keep, renames if any, etc...), with finally a merge button which will ask you for the destination. I'll put a basic rename, wich will look for sprites with a certain name and its children, and rename the parent and the parent part of the children accordingly, but also a mass merge, to insert a bunch of critters of which one instance is in the second Sketch, with a number appended to the base name each time so that they don't get mixed up.
About the Sketch extension: I want to be able to create such Sketches, containing just a complex critter, and upload them to the add-on files for other mapmakers to use, and I want others to do so too (in fact, TrickyEnemy.Sketch is very serious, and I encourage you to use it in your custom levels); also, my next custom level (which is waiting for 1.0.1 to be released) will include a .Sketch version of the boss, for it to be used in other custom levels (when you'll see it, you'll see it can be used as a great mid-level blocking path miniboss, or even not a boss at all, he doesn't need to be a boss). But of course these Sketches can not be played as custom levels, and I want to avoid people mistakenly using them as custom levels (which would be horrible since there is no background, no start position, no walls...). So the easiest way I found so that these Sketches wouldn't be mistaken for custom levels was to change the extension to .Sketch; this way they keep the custom level format (so they can be easily done from a .SketchMap, just remove the Map, and the merging program deals with them exactly as it would with a SketchMap). It's obvious SketchMapMerge will be more often used with these simple Sketches than with full SketchMaps as the addendum, you won't often merge two full maps. So I set the implicit extension for the second file to be only "Sketch". Notice that with input files it still allows you to specify any file name, since if it finds the filen having the filename as you gave it, it will use this file, and only add the extension if he didn't find a file with the original filename; on the other hand with output, the file is assumed to be created, and if the user doesn't want the SketchMap extension there would be no way for him to specify it if I implicitely added it after the filename he gave. So that's the reasoning behind (.SketchMap)-(.Sketch)-nothing.
