As explained above, that array range does NOT map all possible values on a twos-complement machine. It misses the -128 value. It would be correct on a ones-complement or a sign-magnitude machine.
Since fortran has defined the value of the do loop index upon exit since f77, many programs rely on that value after loop exit. If that definition were removed or changed, it would make those formerly conforming codes nonconforming. Then there would be some mishmash of compiler options so that programmers could continue to keep their old codes working with the new standard convention. Within a large program, some do loops would need the old convention while others could use the new convention, so build systems would all get complicated because of that change, and if the wrong compiler options were used on the wrong files, then the code would simply break. These are the types of problems that arise when backward incompatible changes are made to the language.
In your example, there is an easy solution, just use an integer with a different KIND as the loop index. And if the compiler tells you at compile time that there is a problem, then you can fix it in a few seconds and that fix will always be there. You would not need to know which compiler options to use to compile your codes, and if other programmers use your codes, you don’t need to tell them the magical incantations that are required to compile and run your program. So in this case, that seems like the best approach overall.
You are focusing on the index overflow problem. What about the trip count problem? The fortran standard does not require your loop to cycle 255 times, which is probably what you intend. What if it cycles zero times, which I think is what the trip count expression will give you if the overflows are ignored: (127_int8+127_int8+1_int8) evaluates to -1. Do you want the compiler to recognize that and warn you, or should it just remain silent and expect that the programmer knows what he is doing?