See original thread at: https://lists.gnu.org/archive/html/bug-patch/2011-08/msg00004.html

Short summary - there are some contexts, like RPM spec files, where patch series are supposed to be perfect (no offsets).  I encountered a case of an ambiguous patch with 3 lines of context (it took 6 lines of context before the patch became unambiguous), and when generated against the wrong version of the file, the patch was silently applied by 'patch -s --fuzz=0' even though patch had to guess at which ambiguous point to apply the patch.  Worse, 'git apply' picked a different point than 'patch', rendering the rpc broken but only according to which tool chain applied the patch series.  That is, --fuzz=0 didn't reject the patch, and -s hid the message, making the problem undetectable.

If there were an option to reject patch offsets, the rpm would have been identified as broken up front, and the broken patch in the series fixed to list the right offsets for a 0-offset application.  Of course, the option should not be default (offsets are a very useful feature when applying patches from disparate points in time), but clients like rpm patch series would benefit from it.