Right now the cam's greedy optimizer doesn't pay attention to inner vs outer. If I add it then it will get horribly confused by things like this:

Ok, I've managed to do manually. Good combination of filters are enough for now, thanks.

I just released it wouldn't get confused. It'd break apart the paths at the intersections then reform them to do this if I add inner-to-outer:

Just in the pic case, the paths could be on different operations if the behavior is not as desired.
Anyway, I don't know how much workload represents..

this feature would be very valuable for me. i cut many parts with holes. that requires me to select everything by hand. that would be great default with no shortcomings i could see now. it does not need to be perfect and deal with all kinds of situations. simple order of closed contour inside other closed contour would cover 99.99% of situations for me.

As @cojarbi wrote, it's very easy to order features already on CAD side by either use layers or colors. If an automatic order will be implemented in the CAM, it must be possible to deactivate it for manual order.

I didn't realize at first that this ordering might not be desired in some cases. So I totally agree that it should be optionally enabled by user.

Using CAD to split machining operations also involves selecting many shapes by hand. So it does not solve the problem, it just moves it to another software. For example I cut a lot of letters and some of them has holes in them [qopadb..] so I need to select manually all the inside shapes to be cut in first operation before outside shapes can be cut. I'm cutting on a nail bed so cut out pieces falls down.

In the CAD vs CAM approach I think ability to solve this problems in CAD is a workaround for a time while CAM feature is implemented. IMHO CAD (Design) should not care about manufacturing and is not designed to address manufacturing problems. Design software helps to design the part. On the other hand CAM (Manufacturing) should address the common manufacturing problems and help to easily solve them. Cut ordering is manufacture process limitation and ideally should be solved in CAM. So this feature really belongs in CAM.

@tbfleming will the (inner first) reordering of the paths (geometry) before passing to getLaserCutGcodeFromOp do something already?

@jorgerobles I don't understand your question.

Hmm.. well, I mean the cam function getLasercutgcodefromop receives the rawpaths on two parameters. Geometry, array with closed paths and array opengeometry. If we reorder the geometry array using a inner first algorithm, will the function process that way or will reducecampaths reorder again due jsclipper logics? Thanks!

reduceCamPaths will need changes. Maybe an earlier function will mark inside-outside relationships and reduceCamPaths will obey the constraints while reordering.

Are there still plans to add this feature or is this a dead topic?

I would not call it dead but we're all waiting for the next release from @easytarget that addresses a bunch of ageing NodeJS librariries. The way I do it in interim is using a DXF, I have two layers of different colors. I pick one layer color and run this one for inner cuts, then I pick the other one for outer cut. My branch also has an "unoptimized" path so it always starts with the first vertex of the polyline I got in the DXF.