"In Windows Standalone Player, the component on the lower left of the “X“ component also appears as “X“, but in Play Mode, that component appears as the white square"

Oh, that's probably nothing. Guessing one is the "default" scene, while the other is the "example" scene. I would have changed child Image to the default, without using a sprite, just to remove that variable.

So the problem is in Image.IsRaycastLocationValid

This method early outs whenever you aren't trying to do anything with transparency. So if alphaHitTestMinimumThreshold is at the default 0, it just returns true.

As the input system crawls through the UI hierarchy, it stops as soon as an ICanvasRaycastFilter.IsRaycastLocationValid returns false.

The child Image cannot be clicked because the proper behavior for Image.IsRaycastLocationValid *should* be to always return true when the screenPos is outside the Image Rect bounds (and this would mirror the behavior of when alphaHitTestMinimumThreshold == 0), but instead it will sample the nearest texel, and return true when that value is below alphaHitTestMinimumThreshold.

So the interactability of the child Image is determined by the alpha value of the nearest texel in the parent—an absurd behavior that can not possibly be intentional.

Don't be confused by:

if (!RectTransformUtility.ScreenPointToLocalPointInRectangle(rectTransform, screenPoint, eventCamera, out local))
return false;

in Image.IsRaycastLocationValid. While this implies that check fails when the screenPoint is outside of the Image Rect, that method actually only returns false when the screenPoint lies outside the Image Rect *Plane*, not its bounds.

Absent a more substantial refactoring, after the aforementioned lines, but before:

return activeSprite.texture.GetPixelBilinear(x, y).a >= alphaHitTestMinimumThreshold;

the method *must* check whether screenPoint is outside of the Image Rect *bounds*, and return true when that is the case.