G33 issue with LH threads - polarity of the K variable?

I've lost half of the day today trying to figure out why my lathe won't cut a LH thread. I'm using gmoccapy and generating the code with Fusion 360. It's an internal left hand MF18 x 1.5 thread. I finally discovered that I can get it to work if I ensure that the K variable is positive, whereas Fusion had made K negative due to the LH nature of the thread. Presumably the polarity of K is redundant if you have a defined spindle direction of rotation and you have defined the start and end positions of the thread. Conversely, specifying a negative value will create a conflict when you are cutting a LH thread with a "forward" spindle rotation, which is presumably why my machine refused to proceed, although there was no error message that I could see.

If I'm right, I guess this is another case where the Fusion post processor will need to be modified to ensure it only outputs a positive value for K. I will try to bottom this out but I was wondering if anyone else has encountered this issue?

Example file attached
 

Although G76 seems to be more highly evolved and powerful than G33, the Fusion posts for both LinuxCNC and Centroid (my other lathe) prefer to use G32 (Centroid) or G33 (LinuxCNC) multiple times at increasing depths and angles, rather than make use of the myriad options to handle that directly within G76. 

I see that my current post is v43470, which generated the problematic code I posted above. However, when I try the latest post v43725, it fails. There seems to have been a fair bit of evolution of the LinuxCNC post processor of late, although as seems to be the modern way with software engineers, they seem to need to fling it at the wall many times before it sticks. 

I guess I may choose to experiment with the interim "releases" to see if I can get one of the more recent versions to not fail and see if it behaves differently / better. On a more positive note, the LH thread came out very nicely, so I doubt I will be encountering that problem again any day soon.

I've done a fair bit of Fusion post processor editing over the last few years. As you say, they are written in Javascript and there's excellent plug-in support in (free) Visual Studio Code. You can even debug a post with line-by-line highlighting of the relevant Javascript as it processes the intermediate file.

Here's the current status for the LinuxCNC post on the Fusion site (the forum software has garbled it nicely though)
TurningVersion: 43725Changed: 23 days ago
Extension: ngc
Downloads: 123
4372529/03/2022Post properties are now displayed within tabbed groups in the NC Program dialog.
4359214/01/2022Updated the generic posts to use the new WCS definitions.
4358812/01/2022Force the coolant codes after a Stop or Optional Stop
4346212/10/2021Added the ability to specify the coolant codes as a text string.
4341808/09/2021Fixed undesired expansion of tapping cycle in generic turning posts. (#1135)
4321413/04/2021Standardize retract logic across all lathe posts. (#893)
4315119/02/2021Updated all posts to use the new property definitions. You must have post engine version v4.5702 or higher to use this post. (#849)
4306711/12/2020turning posts with latest setCoolant code (#743)
4288531/07/2020Added property to expand cycles, added rigid tapping, and expanded workoffset support.
4282415/06/2020Fix I parameter in threading cycle. (#497)
4281404/06/2020Add threading to LinuxCNC turning. (#486)