Book 1: For shadow acne, doesn't ignoring hits close to the intersection point lead to other problems?

[DeltaPavonis]

Section 9.3 of Ray Tracing in One Weekend describes the fix to shadow acne as follows:

The calculation [of the intersection point] is susceptible to floating point rounding errors... This means that the origin of the next ray... might be just below the surface. If the ray's origin is just below the surface... it will find the nearest surface at t=0.00000001 or whatever floating point approximation the hit function gives us. The simplest hack to address this is just to ignore hits that are very close to the calculated intersection point.

However, I believe that adopting this approach — changing the valid interval for hit-times from $(0, \infty)$ to $(0.001, \infty)$ — leads to a bigger problem.

• Say that a ray $R$ intersects some sphere at two times $0.0007$ and $1000$.
• Now, call ray_color(R). The function will call Sphere::hit() to find the minimum hit-time.
• However, $0.0007 \notin (0.001, \infty)$ and $1000 \in (0.001, \infty)$, so this will report that t = $1000$ is the desired intersection time!
• In reality, t = $1000$ represents the intersection of the ray $R$ with the inside of the sphere. As a result, the surface normal at the intersection point will point into the sphere, and so the next ray will also be inside the sphere, and so ray_color will recurse over and over again. The rays will keep bouncing off the inside surface of the sphere until this same error, once more, causes the ray to "warp" outside of the sphere and fly into the background.

Summarizing, the problem here is that
(a) The correct intersection time is ignored because it is too close to 0; and
(b) The other intersection time happens to be positive, and happens to represent the ray's intersection with the interior of the object, causing a large number of recursive calls to occur.

So, my question is, shouldn't the code use the front_face variable to prevent shadow acne (by making sure that rays intersect the exterior of a surface if and only if they originated outside the surface, and analogously for surface interiors)? If the current method of tweaking the time interval has problems like this, why do we use it?

(I am aware that Section 9.2 of Ray Tracing in One Weekend introduces the idea of bounding the recursion stack. While that would help for the specific issue I've mentioned, it wouldn't solve the root problem: that the wrong solution is being chosen because all solutions in $(0, 0.001)$ are discounted. However, as mentioned above, wouldn't just checking which surface the ray intersects at fix this root issue?)

If needed, I have found a specific input that causes the provided code to recurse more than $50,000$ times on a single call of ray_color, that shows this exact behavior: A randomly-generated ray bounces between the two spheres before warping into the second sphere and bouncing off its inside surface more than $50,000$ times, before warping out again and flying into the background. I also have highly-detailed logs showing all calls of ray_color. If you would like to see them, feel free to ask!