why does this single wall object get cross-object travel moves  

RE:

Wish I had the answer to your specific question but I don't (watching this thread to hopefully learn something). 

But one small comment regarding the SCAD script. The way the difference() is done makes the top and bottom surfaces of the boxes coincident (in the same plane), which can cause errors in the STL. It doesn't seem to cause a problem in this specific example but it's best practice to avoid it. 

Just add a small amount (e.g., _min = 0.01) to the intersecting body (and adjust for it as needed in any translate() operations).

E.g.:

_min = 0.01;

translate([0,0,my_h/2]) {
  difference() { $fn=30;
        roundedBox([my_l1 ,my_l1,my_h],3, true);
        roundedBox([my_l1-(wall*2),my_l1-(wall*2),my_h+ _min],2.5,

From the OpenSCAD manual for union() https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/CSG_Modelling#union

Note: It is mandatory for all unions, explicit or implicit, that external faces to be merged not be coincident. Failure to follow this rule results in a design with undefined behavior, and can result in a render which is not manifold (with zero volume portions, or portions inside out), which typically leads to a warning and sometimes removal of a portion of the design from the rendered output. (This can also result in flickering effects during the preview.) This requirement is not a bug, but an intrinsic property of floating point comparisons and the fundamental inability to exactly represent irrational numbers such as those resulting from most rotations. As an example, this is an invalid OpenSCAD program, and will at least lead to a warning on most platforms

And for difference():

Note: It is mandatory that surfaces that are to be removed by a difference operation have an overlap, and that the negative piece being removed extends fully outside of the volume it is removing that surface from. Failure to follow this rule can cause preview artifacts and can result in non-manifold render warnings or the removal of pieces from the render output. See the description above in union for why this is required and an example of how to do this by this using a small epsilon value.

RE: why does this single wall object get cross-object travel moves

But one small comment regarding the SCAD script. The way the difference() is done makes the top and bottom surfaces of the boxes coincident (in the same plane), which can cause errors in the STL. It doesn't seem to cause a problem in this specific example but it's best practice to avoid it. 

Just add a small amount (e.g., _min = 0.01) to the intersecting body (and adjust for it as needed in any translate() operations).

Thanks, I had not known it was more than a cosmetic rendering issue. 

As for the slicing and all the travel moves across the object, I removed 2 holes from the opposite wall so only 2 side-by-side remain and that slices without the across-object travel moves. I'd even tried the 2.6 beta and painted some seams but the slicer insisted on traveling across the object. Even after painting all the holes with no-seam markings. 😕

RE: why does this single wall object get cross-object travel moves

Posted by: @doug-larue

I can't seem to figure out the right setting in Prusa Slicer to get there now.  It's been a while since I used this and it was with Slic3r and later with Prusa Slic3r.

The problem lie in the bad travel engine that PE still use, for example:
https://github.com/prusa3d/PrusaSlicer/issues/10756

There's no way, while tuning settings, to truly reduce non printing movements and obtaining a very smart travel management, like Cura or Simplify3D are able to achieve.

So you need to patiently wait, like the rest of us, a complete review of the actual travel engine by the developers.

RE: why does this single wall object get cross-object travel moves

The problem lie in the bad travel engine that PE still use, for example:
https://github.com/prusa3d/PrusaSlicer/issues/10756

There's no way, while tuning settings, to truly reduce non printing movements and obtaining a very smart travel management, like Cura or Simplify3D are able to achieve.

ouch!  I was thinking it was just some setting which was related to part cooling, ie spend time moving the nozzle around lets the previous plastic cool enough for another layer to prevent sagging.  I still have Z-lift enabled which is probably what the people who find all this moving is busting off supports from the print bed.

This seems a pretty fundamental capability that it would have been ironed out long before something like Input Shaping were added.  Thanks for the response.