Load attached brep file, the face's tessellation is not good as expectation using tolerance 0.045 and API BRepMesh_IncrementalMesh.
I have tried it using Hypermesh and SolidWorks, and their results are good.

The face is planar (built on a planar b-spline surface of degree 1) and has edges based on C0 curves, with knuckles. Triangulation algorithm does not respect these knuckles, producing tesselation that deflects from the actual curves by about 15 mm (my estimate). Note that this deflection is not reported by trinfo command.

We need to improve tesselation of edges to make it accurate and respecting the requested deflection.

Cross face errors are appearing due the rude deflection and partially invalid shape used in these test cases.

grid mesh standard_shading(001) K9:
Changing the edge sampling leads changes of the area and I suppose ~ 1.5% is not critical. Moreover, consequent fixes of the BRepMesh can turn this case back to the initial state.

Comparing the visual representations of the shape I establish the current representation is a little bit better than reference one.

Regarding to the test cases:
I suppose it will be more informative to display results in the top view:

tclean result
incmesh result 0.045
isos result 0
triangles result
top
fit

It's also useful to check areas using the triarea command to control possible changes in future.

I've checked the information produced by tricheck and the command itself. So, in general: it performs iteration through the nodes of triangulations of two faces and compares the distances between the nodes with the same indices (that is actually incorrect, because it should perform checking "each to each" at least, as far as the distribution of nodes of a single face is independent of distribution of another one) with maximum deflection of comparing faces. I've used debug information and the following script to contrast incorrectness of behavior of tricheck command:

At the attached screenshot you can observe the pairs of vertices {1_1, 1_2} and {2_1, 2_2} lying on the shared edges. The function calculates distance between points of a pair (0.0782227 and 0.080904 correspondingly) and make decision that it doesn't fulfil the deflection (0.017369606982662045). So, this case is considered as a crossed faces error.

In conclusion, I propose to exclude this kind of errors from considering of regressions for the current state of tricheck functionality .

Fucnctionality of the cross faces check should be improved to provide more sensible results or should be eliminated at all.

The check of cross-face errors should not be eliminated. It is well defined (see MeshTest_CheckTopology.hxx):

//! - cross face errors. It is a situation when a point on a common
//! boundary between two faces has different 3d coordinates on each
//! triangulation. The error is reported if the distance is greater
//! than a deflection written in triangulations.

I would change this definition, in order to compare distance between nodes of triangulation with the real distance between curves representations (value returned by the DRAW command computetolerance), rather than with mesh deflection.

As applied to this problem, we checked with OAN and found out that the common edges in the shape have improper samerange/sameparameter flag, because the command computetolerance returns the value about 0.02, while the edge's tolerance is 2e-5. BRepMesh trusts the flag SameParameter, and when a new point is inserted in some polygon on triangulation, its insertion into another polygon with the same parameter gives wrong point.

So, the solution would be to stop trusting the SameParameter flag (recompute the flag locally).