“waiting for at least 2 compilers to implement a feature” is “needlessly conservative”, IMO. Especially on Windows OS where 100x or more billions of $$ of work is done where there is only one compiler.
Separately if you base matters on gfortran, that essentially places you in the position of sticking to some arbitrary keystone and circling around it, whatever that be. For the comp.lang.fortran thread, that keystone was FORTRAN 77 plus that OP’s pet features. But you can pick your own “poison”, Fortran 95 or whatever. Otherwise with anything else, you can’t go with a “tickmark” in any compiler support list (ACM Fortran or FortranPlus.co.uk or whatever) and run with it. Like in this comment of yours, you will soon be “fed up with … compilers that claim support for a feature, but have a half-assed implementation that only works for simple usage and fails badly for more complex usage”
The bottom-line is the comp.lang.fortran post I linked starts with “a constant series of problems” and that’s otherwise the constant world of Fortran.
A far more preferable approach, I firmly believe, is to forge ahead with the standard and making the processor implementations to follow; the processor shown upthread with the Fibonacci sequence example has been really good at it of late, supporting all of current standard (bugs notwithstanding for which they constantly face a barrage of support requests from me which they gamely fix rather quickly too). Employing that processor for “good” advertisement of Fortran is all that makes sense now.