Very simply; IF MODIFIED does not work the way most programmers think it works, and indeed, would want it to work.
I am attaching an issue of Inside Natural from eight years ago. The relevant discussion begins on Page 9. As you will note, if you read the article, REINPUT basically renders IF MODIFIED subject to two types of “errors”. Natural will tell you a variable was MODIFIED, when “logically” it was not modified. Why? The variable was modified twice; once via INPUT and once via REINPUT (back to the original value). Natural (see attached article) will tell you that the variable was modified, despite the fact that most people would like to be told “not modified”. Consider a Map I change a variable from ABC to XYZ. Before pressing enter I change it back to ABC. Natural will, very properly in my opinion, report “not modified”. Yet if there is a REINPUT in between, the verdict is modified.
As shown in the attached article, the converse is also possible. I change a variable from ABC to XYZ. Based on some other variable on the screen, my program does a REINPUT FULL. I leave the XYZ variable the same. Natural tells me (after the REINPUT screen) that the variable is “not modified”, when clearly it has changed from ABC to XYZ.
Yes, I have seen people play games with complicated code (lots of flags, etc) to get around this problem. I have chosen, in my code to go back to the “old way”; two sets of values for variables where changes must be tested. Then I can compare old values versus new values.
The real “problem” is the IF MODIFIED logic can be a time bomb in your program, waiting to go off. If a user never enters data that causes a REINPUT, the IF MODIFIED will work perfectly. Then, usually 2 am on a saturday morning, comes the dreaded call that a critical international online application, being run half way around the world (where it is 2pm), has blown up. Not fun.