There’s one feature I’d live to see incorporated into slicing software and printer interface software and I’m putting the idea here for anyone to use or not.
It would be great if while printing multiple objects, if you had a print failure on an object, you could discontinue the printing of the failed object while continuing to print the other objects.
You would need some way to flag the lines of gcode related to each object or provide a custom gcode command to identify the start and end of blocks of gcode belonging to each part and to selectively disable (skip) them from the printer interface software.
End result being that, as you’re printing, perhaps there’s a late design change, defect, warp or other kind of failure on one part, but it’s not interfering with the other parts, just choose the part from the printer interface (via list or the preview display) and tell it to discontinue printing the specific part but finish he rest of the print.
If you were using absolute filament length then you would need to jump the filament position value to the amount on the last line of the skipped block but it doesn’t seem like it would be that difficult.
Well, just an idea at any rate, but I think one that would be really handy to have and not terribly difficult from the programming side of things.
Well you can tell slic3r to finish objects one a time, instead of printing them simultaneously.
Definitely sounds like something I would only enable if you were using relative filament length - after all, for absolute, you would need to edit the filament length of every referencing G-code post-removed object on every layer. But with relative extrusion and a marker it is not infeasible.
That’s true Thomas, but it’s useless for tall objects.
Howard, for absolute you wouldn’t reprocess the whole file at once when you removed an object, you would set and extruder offset value and modify each line to affect that offset on the fly in the gcode as it’s sent out to the printer, which is very trivial and low processor load when compared to drawing out a toolpath on a 3D rendered model in the view window 
Cool to see, Whosa. I would think one would take the slicer + printer interface software approach over a a firmware solution as the firmware just eats gcode which it is spoon fed continuously from the printer interface software, which is running on a much more powerful processor (unless reading from an SD card of course).
The idea of skipping anything in region x1,y1 to x2y,2 like Ivan mentioned and I saw on GitHub could be handled in firmware and would solve the same problem for basic shapes, but maybe not efficient for heavily nested complex shapes such as printing a series of nested arches, etc?