Function route_reading 

pub fn route_reading(
    solid: &BrepSolid,
    moved: &[u64],
    motion: &AffineTransform,
) -> Result<RouteReading, KernelRefusal>

Which faces a moved selection’s carriers would open a NEW hole in.

What this measures, and why it is not a case table

The carrier road re-solves the EXISTING topology’s geometry against the moved carriers. That is right for as long as the moved group keeps the neighbours it has: every boundary it owns is a loop that is already there, and re-solving moves it. It is wrong the moment the motion carries a boundary onto a face the group does not currently touch, because there is no loop on that face to re-solve — which is the migrating mouth, and it is why that cell refuses on both roads today.

So the question “does this motion need the rebuild road” is exactly “does some moved carrier, after the motion, pass through the TRIMMED REGION of a face it does not currently bound”. It reads no surface type and no configuration; a plane, a bore wall and an imported free-form patch are all asked the same question.

The two halves, and which one already existed

The SECTION half is the kernel’s own intersect_surfaces. Note that carrier_section above is NOT usable here: it seeds its march from the edge it is replacing (edge_seeds), and the whole point of this question is faces that share no edge with the moved group, so there is no seed to take.

The TRIMMED-REGION half is parameter_point_in_face, and nothing on the carrier road called it before this: the road only ever asked about carriers it already had an edge on, where containment is not in question. A section that crosses a face’s CARRIER but misses its trim is the ordinary case — a bore sliding along inside its own slab passes through the plane of every wall in the body and opens a hole in none of them — so the trim test is what separates a migration from a motion that merely moves.

Faces the group ALREADY bounds are excluded: a section there is the first half’s job and is not a topology change.