So, in the queuing-phase (also in all other phases as well) there is no layer-comment from the slicer. Of course I could ask @foosel, " please add a Hook that provides all lines and not just the G-Code lines ", I'm not sure why I haven't done that in the past...hmmm, maybe a feature request for octoprint or better a pull-request 
I've already asked for this, and there are apparently some complications. It would be EXTREMELY useful, however. Maybe the complications can be eliminated somehow.
Wow...heavy shit...I looked into your C++ source code....holy moly...how long did it take you to do that ?
Answer: A long ass time. Most of the complications were figuring out how to communicate to and from Python. That stuff is crazy. I've written other extensions like this in other languages, and Python is by far the most difficult I've worked with. In fact, there still might be a memory leak in the portion of the code that sends the snapshot plan information back to python. It is very difficult to tell, actually, though I plan to get to the bottom of that soon. The straight c++ was mostly simple (I just translated my python code, more or less, it somewhat, and added what was needed to pre-calculate where snapshots would be taken), except for the fact that c++ versions were very difficult to keep straight. As a general rule, any features in c++ v11+ needed to be removed, else many compilers would fail. However, it is SO SO much faster than python. Also, it is a bit messy because I couldn't really plan how it worked up front since I was learning to interact with python via trial by fire. I have been refactoring things, and will eventually fix it up so that it doesn't smell so much or make one's eyes bleed (which it does, and so does Octolapse).
I don't mean to hijack the thread, but I figure I'll explain how the processor can be used to help you determine if it's worth investing the time, or if a simpler method would be better. I can edit this comment and remove this wall of text if it distracts from your purpose, or I can move it into another thread in the development category. Let me know if I should do this!
Calling the extension from python is easy (using the gcode_processor.py module, currently tailored for Octolapse).
Initialization:
GcodeProcessor.initialize_position_processor(cpp_position_args)
The args are a bit complicated, but not everything is needed in most cases (i.e. just layer change detection):
{
"location_detection_commands": self.get_location_detection_command_list(),
"xyz_axis_default_mode": self.xyz_axes_default_mode,
"e_axis_default_mode": self.e_axis_default_mode,
"units_default": self.units_default,
"autodetect_position": self.auto_detect_position,
"slicer_settings": {
"extruders": [
"z_lift_height": 0,
"retraction_length": 0,
]
},
"zero_based_extruder": self.zero_based_extruder,
"priming_height": self.priming_height,
"minimum_layer_height": self.minimum_layer_height,
"num_extruders": num_extruders,
"shared_extruder": self.shared_extruder,
"default_extruder_index": default_extruder - 1, # The default extruder is 1 based!
"extruder_offsets": extruder_offsets,
"home_position": {
"home_x": None if self.home_x is None else float(self.home_x),
"home_y": None if self.home_y is None else float(self.home_y),
"home_z": None if self.home_z is None else float(self.home_z),
}
You could set all axis to absolute by default, leave the home positions as None (they will autodetect after homing). A minimum layer height of 0.05MM seems to work in most cases for vase mode if you don't know the layer height. The slicer settings per extruder can fudged if you don't care to track z_lift or retraction, and you can pretty safely just configure a single extruder and it will still work. Priming height is required to detect purges, but in 99% of the cases a setting of 0.5MM will do the trick. This will work for purging on the bed, or in mid-air for pretty much all of the gcode I've encountered.
Updating the current position with gcode is super easy:
GcodeProcessor.update(gcode, self.current_pos)
It spits a dict of the current printer and extruder state into the second parameter (see gcode_processor.py for the Pos and Extruder classes, which explain what is returned).
You can also undo commands (a fixed number, currently up to 10), in case they aren't sent to the printer:
GcodeProcessor.undo()
I plan to add an undo that takes gcode, which would reverse a gcode update, giving unlimited undo, but that will take some work.
You can fetch the current and previous position and state:
self.current_pos = GcodeProcessor.get_current_position()
self.previous_pos = GcodeProcessor.get_previous_position()
You can even manually override the current location, which is useful in some situations:
GcodeProcessor.update_position(self.current_pos, x, y, z, e, f) # all in absolute I believe.
Also, there is a comment processor in the c++ code for extracting comment based information per slicer (it auto-detects the slicer type), but right now it only tracks things like feature type (infill, perimeters, etc), but not layer changes (it does that via a different method). It could be easily modified to do that too, however.
The main problem with it right now is that it needs to be compiled. See setup.py for info there. I would rather it be installed via pip, but that will take some work, and would require some refactoring to separate out the Octolapse stuff (snapshot plan generation) from the rest (parsing and position/state processing).
I hope that helps, and even if it does not I look forward to seeing what you come up with!