Wire/Edge orientation bug?

I'm iterating over all wires for a given face and then iterating over the edges within each of the wires to build local loop definitions consisting of an ordered set of edges and their relative orientations. Though the resulting edge ordering appears correct, the query for the edge orientation seems to yield an inconsistent result. For some models no issue appears with the loops while for others, some of the edge orientations are clearly the reverse of what they should be based upon examination of the vertices.

Here's the code I'm using:

For a given TopoDS_Face face...
TopoDS_Wire outerWire = BRepTools::OuterWire(face);
// define a wire iterator for the face
TopExp_Explorer expWire;
for (expWire.Init(face, TopAbs_WIRE); expWire.More(); expWire.Next())
{
const TopoDS_Wire& wire = TopoDS::Wire(expWire.Current());
// set the loop type from the wire type; the kernel defines only inner and outer types
if (wire == outerWire)
{
loopType = Dis::Srf::Outer;
}
else
{
loopType = Dis::Srf::Inner;
}
BRepTools_WireExplorer exp;
for (exp.Init(wire); exp.More(); exp.Next())
{
// get edge orientation (forward or backward running)
TopoDS_Edge edge = exp.Current();
TopAbs_Orientation orient = exp.Orientation();
bool use = (orient == TopAbs_FORWARD ? true : false);

For the attached model (a zipped step file) a check on the continuity of the endpoint vertices from edge to edge reveals the poorly formed loops (here I'm displaying ids assigned to each entity type):

There were 4 improperly defined loops detected.
Surface: 2, Loop: 0, has 5 edges
Edge 8 from 9 to 8
Edge 9 from 8 to 10
Edge 10 from 11 to 10
Edge 11 from 12 to 11
Edge 12 from 12 to 9
Surface: 29, Loop: 0, has 12 edges
Edge 119 from 115 to 110
Edge 110 from 110 to 106
Edge 120 from 101 to 106
Edge 101 from 101 to 102
Edge 121 from 102 to 116
Edge 122 from 116 to 10
Edge 123 from 117 to 10
Edge 124 from 117 to 118
Edge 125 from 118 to 118
Edge 124 from 118 to 117
Edge 126 from 12 to 117
Edge 127 from 12 to 115
Surface: 30, Loop: 0, has 12 edges
Edge 120 from 106 to 101
Edge 106 from 106 to 107
Edge 128 from 107 to 115
Edge 127 from 115 to 12
Edge 11 from 11 to 12
Edge 129 from 119 to 11
Edge 130 from 119 to 119
Edge 129 from 11 to 119
Edge 10 from 10 to 11
Edge 122 from 10 to 116
Edge 131 from 116 to 105
Edge 105 from 105 to 101
Surface: 65, Loop: 0, has 5 edges
Edge 9 from 10 to 8
Edge 178 from 8 to 9
Edge 12 from 9 to 12
Edge 126 from 117 to 12
Edge 123 from 10 to 117

The improperly oriented edges are easy to pick out. If I programmatically reverse the indicated orientation for those particular edges, all resulting loop definitions are good.

The attached image shows the surfaces for which the loops are incorrectly defined.

Scratching my head over this one. Is it a model problem or a bug? Any and all help would be appreciated.