@John_Mc - Yes, the issue is the same. It is not with the slicer or sliced code per se, but with the start Gcode scripts pre-pended onto the sliced file.
With 1.1.5.xx or later, moves while an endstop is triggered can alter the leveling matrix, causing all kinds of Z coordinate issues, and attempted moves beyond an endstop result in incorrect coordinates that affect subsequent moves. In the case of the Mini, the G29 coordinates actually caused the latter problem -- not sure whether that applies to the Taz6 or not -- but the rest does. Version 1.1.5.xx and later change how the leveling matrix and endstops are handled.
As long as you adopt the new start gcode, you're OK with any slicer. Specifically, three things:
(1) Don't make any Z moves when an X or Y endstop is triggered -- so for example, don't "home" and then move up/down before moving XY away from the endstops. When writing gcode, always "move away from the endstops" immediately after any G28 operation.
(2) Check that your start gcode doesn't attempt to move beyond X or Y endstop -- on older 1.0.xx firmware, the current_x and current_y were clipped to the endstop value when that happened, but with 1.1.5.xx and later the position becomes invalid. For example, if X_Max is 159 and you execute a "G1 X170", movement will obviously stop at 159 but current_x will still be set to 170 (older firmware would have clipped it to 159). The problem with that is that the next move is referenced from X170 instead of X159 where it actually is.
(3) You may need to add a "G28 XY" (and then move away from endstops) after the G29 sequence completes. I say may because it is model-specific; the G29 coordinates exceed endstops on SOME sub-models of the mini, and not on others -- not sure about the Taz6. Rehoming XY corrects any incorrect XY coordinate that may have been caused by an attempt to move beyond the XY endstops.
Hope that helps...