The weakness of the Heeks implementation was that it didn't handle profiles with multiple disconnected wires where the user needs to configure multiple start points.

can you give some more info on that? Do you mean rapid moves between entry points in a connected toolpath or is there a toolpath that will produce disconnected wires?

Taking as an example your image below with an outside contour and five inside contours. Each of the inside contours is a wire with one or more edges and the CNC must rapid between them. If the user picks five points to identify start points, you must keep track of which point corresponds to which wire. This is where I remember HeeksCNC being weak. For simple cases, it's, well, simple. But it can get more complicated.

How did it handle the start and stop points? as one point with overlaps (negative tag width) or 2 separate points for stop and start?

Start and end points were distinctly different. IIRC, the algorithm insisted that the entire profile be traversed by the tool and took into account the direction of travel. So if you accidentally, set the exit point on the wrong side of the entry point relative to travel, it could cause most of the path to be traversed twice. I think it would start at the start point and go all the way around to the start point and then look for the exit point.

Taking as an example your image below with an outside contour and five inside contours. Each of the inside contours is a wire with one or more edges and the CNC must rapid between them. If the user picks five points to identify start points, you must keep track of which point corresponds to which wire

IMO It's the user that picks the startpoint on the base Operation what is the original Startpoint, All toolpaths (except engrave&deburr) have this setting.In most cases that would be the tool-change position or end of previous op. For this you will need to pick a point in free space.

This dressup would move the engagement points (were rapids become moves) along that baseOp path, which would be one continuous wire already containing the beginning and ending of all contours in separated by rapids. In the Tag code: isEntryOrExitStrut. This way we don't have to track them just recalculate.

The LeadInOut does somewhat similar, it finds these engagement points and lets you modify them. it also applies multiple times in one OP. When splitting into EntryStud(Start engagement) and ExitStud (End engagement) there's a piece we either miss or double cut in 2D. In 2,5/3D there is a height difference and requires them to be treated different anyway. Being able to control how engagement ends ie: moving in on pocket bottom or after a overhang cut before moving up is actually a leadOUT

I'm not sure it's the right place to put it (and I have no idea by what magic PathHelix sorts holes, because my old code doesn't seem to be used in there and there is nothing that looks like sorting to be seen).

It seems to handle overlapping shapes reasonably well (at least better than no sorting whatsoever):

Screenshot from 2019-03-14 22-09-33.png (18.32 KiB) Viewed 219 times

If PathAreaOp is the right place for this I'll play around some more (maybe it's better to calculate the center of the shape instead of [XMin, YMin], or to run the operation twice - first time to get start and end points, second time to sort based on those, because I have no idea how why it decides to start on the furthest point from origin...)

not sure this is the right thread, but... I got some time to build things again, Path has improved a lot in the mean time, but one thing is unchanged

...

If PathAreaOp is the right place for this I'll play around some more (maybe it's better to calculate the center of the shape instead of [XMin, YMin], or to run the operation twice - first time to get start and end points, second time to sort based on those, because I have no idea how why it decides to start on the furthest point from origin...)

Can you please include your test file so it's possible to compare apples to apples?

Had some time again and updated the Startpoint picker from 2 posts above, for single engagement-point operations this works well.
Also it produces less screen clutter(on parts with many ops) as a screen full of green spheres like the holdingtag gui does.

Done some test on m0n5t3r 's file as well as on some of my own. The problem could be solved if we tooled each feature separate, so each engagement would be it's own operation for which a startpoint can be set.

Next up my list is to have this somehow automated, not having to select each hole and dressups separate. While gaining some control over where the initial startpoint will be.