When a developer enables both the "plane" and "mesh" entityType, what should they expect when hit-testing against a relatively flat surface?

• Would they get two XRHitTestResult instances for each surface, one for the surface's plane geometry and one for the same surface's mesh geometry?
  • If so, is it random whether the site sees the plane or the mesh first in the list, based on whether the mesh geometry happens to dip above or below the idealized plane along that particular ray?
  • Note that there is no output entityType on an XRHitTestResult, and so an app can only pick the first result's position and normal. If there is a material difference in normal stability for "plane" vs. "mesh" hit test results, the placed object may judder unexpectedly as the user scans the ray across areas where the mesh dips above and below the plane.
• Would they get one XRHitTestResult instance for each surface, with the UA hiding the mesh collision at points where the same surface has a higher-quality "plane" normal to offer?
  • In this approach, the site's request for "mesh" entities is primary an opt-in to hits against additional curved surfaces that don't have planes.
  • If UAs go this way, is there a difference between requesting ["mesh"] entities vs. requesting ["mesh", "plane"] entities? Does a single entityType member or a planesOnly bool (as discussed in Can "point" just be subsumed into "mesh"? #66) make more sense then?

If different UAs diverge in the path they choose here, it will likely cause non-conformance across devices for sites that request ["mesh", "plane"] hits. We should be more prescriptive in the spec on how many hits at most are expected per real-world surface.