A Feedback report would be useful for diagnosing this, preferably with a reproducing project though since iOS 16.4 a sysdiagnose may be sufficient. As that linked thread indicates, -[NSFetchedResultsControllerDelegate controller:didChangeContentWithSnapshot:] will yield an NSDiffableDataSourceSnapshot that can be used directly with UIKit's diffable data sources API without causing any faulting behaviour. This approach is not quite as performant as using the per-change methods in some situations (very large views with very few changes) but it has the benefit of being self-healing when something goes wrong. In any case, it would be useful to see this problem in action—assuming the NSFetchedResultsControllerDelegate ↔ UICollectionView adapter is faithful it could indicate a bug in UIKit.

Am I understanding it correctly? Yes Is there any way I should be able guess this behavior? Not really? As Jordan hinted (https://mobile.twitter.com/UINT_MIN/status/1407035602864910340) the setters are nonmutating, which is a strong hint that there are shenanigans going on, but doesn't tell you anything about the shenanigans themselves. In general the "perform fetch on getter" behaviour is a compromise based on what was possible in the moment. For completeness, the downsides of not using that local variable are that the fetch will be performed multiple times (which is not performant) and one of them may fail due to discontiguous sections (SwiftUI should swallow the error but you'll see logging). It should "work", but it may generate a fault. I'm hoping these calisthenics won't be necessary in the long arc of history but the talk (and the docs) have to reflect the perils of the moment.