old and standard-conforming! That’s a hoot, alright!
The language standard for Fortran has deleted quite a few features that are error-prone and more detrimental to current and future practitioners than beneficial:
arithmetic IF,nonblock DO construct,Hollerith edit descriptor
to name a few. These features are actually employed in legacy codebases at a far greater frequency than implicit mapping, the latter being understood since 1970s, i.e., over 50 years ago, as pernicious and for which the implicit none alternative as a non-standard extension was immediately accepted by practitioners, so much so that the Fortran 90 standard over a dozen years after the ANSI 77 version had no recourse but to standardize it.
So did the sky coming falling down because the above features such as arithmetic IF, nonblock DO, Heolleriths, etc. - staple features in “old” codes - were deleted from the standard and because a conforming compiler would throw errors at compile time?
No. in fact the few and far in between folks, who look at the old FORTRAN code and are mostly revulsed by it, are happy if the compiler can give them some meaningful guidance to move forward. Some processors go out of their way like Intel which forces its users to do extra work to get new, standard-conforming behavior. So what is the problem with old code and future standard revisions? There is none, actually.
On the other hand, the voting members of the Fortran committee can be quite blasé when it is convenient for them to make subtle breaking changes which can silently and adversely affect program behavior such as the one change in Fortran 2023. None of the voting members nor the Community here appear to be bothered by it. Sure if a Fortran 2018 program being actually used in industry fails, so what - hell with it, they can go pound sand is the attitude, let the industry manager(s) budget for a migration to any one of the 20 or so programming languages / platforms that have >99% of the attention and positive rating of practitioners who want to write better and more performant code than with Fortran that has <0.8% rating and which holds on to implicit mapping when an overwhelming majority want to author type-safe code.
The alarm by @RonShepard about backward compatibility above, though kept general, is in reality only alluding to a couple of changes, like implicit mapping and implied save. These needless alarms are only hurting the language and its current and future practitioners besides ignoring and being inconsistent with goes on with Fortran.
The actual history of Fortran is in fact that more than several but consequential backwardly incompatible changes have been made and they continue to happen, like I have listed above.