Same class here on 24A5408d, but outside a horizontal ScrollView, which may widen the scope of this regression. My container is a vertical SwiftUI Form (a preview area plus several controls, inside a NavigationStack with a pinned bottom bar). There is no horizontal ScrollView anywhere on that screen. The signature matches yours exactly: the element reports isHittable == true, the synthesized event appears to complete, and the bound value never changes. Affected in my measurements, all in the same Form: Slider via adjust(toNormalizedSliderPosition:); Stepper increment buttons, four consecutive taps with the bound value unchanged; onTapGesture(coordinateSpace:) on a container view; simultaneousGesture(SpatialTapGesture()), the workaround DTS suggested in thread 795909 for FB19394663, equally ineffective here; and DragGesture on a view inside the Form. Two differences from your report. First, it is intermittent, not consistent: the same synthesized tap at the same normalized coordinates was delivered in one run and dropped in the next. That also makes it impossible to gate in a test suite, since neither a positive nor an inverted expectation is stable. Second, it is far worse in compact height (landscape); in portrait the same controls mostly work. The iOS 26.0 simulator (23A343) runs the identical app build reliably, and element geometry is bit-identical between the two runtimes for the same screen. Filed as FB24381580. NSPsychic, that is an interesting lead, thank you. Does scrollEdgeEffectHidden(_:for:) help only on the inner horizontal scroll view in your case, or does hiding the top edge effect on the outer, vertical container matter as well? Given that my failures are worst in compact height, where everything sits close to the top edge, and that the report above describes taps near the upper portion being ignored while the lower edge works, an edge-effect overlay would fit the pattern. I will measure it and report back.