Hi,

<<<
"First, elemental implies pure -- elemental is all you need" - no, not with Fortran 2008.

As Neil commented, Fortran 2008 has not changed the meaning of the ELEMENTAL keyword, so a Fortran 95/2003 program using ELEMENTAL has identical semantics, i.e. in the absence of IMPURE, ELEMENTAL=>PURE.

<<<
So how does NAg compiler in terms of -C=recursion (or -C=all)?  Is that on by default?

No.

<<<
 And is there a way to turn it off?

The -C=recursion option turns it on.  Omitting the option leaves it off.

<<<
 And when the check of "invalid recursion" (via -C=all or -C=recursion) is applied, is it checking against the current Fortran standard (which simply has an artificial constraint)

It is NOT an artificial constraint!

<<<
or a true systems problem where recursion can lead to stack corruption, etc.

A procedure that is compiled as being "non-recursive" can do static allocation of (non-automatic) local unSAVEd variables.  Obviously that is going to silently return the wrong answer if it gets called recursively.  Thus there is a good reason for the existence of the RECURSIVE keyword in the standard and the -C=recursive option for the NAG compiler.

Fortran 2015 still permits non-recursive procedures, the change is that "by default" every procedure is recursive.  You can declare a procedure to be non-recursive using the (new) NON_RECURSIVE keyword.

should cause no other true application issues at the assembly level - no stack corruption, no memory leaks,

With current hardware it is not stack corruption that is likely to be the problem, it is the possibility of silent wrong answers.

I have tested it extensively with Intel compiler.

It might well be that the Intel compiler has put some or all of your local variables onto the stack (instead of statically allocating); different compilers are known to use different heuristics for this, and the heuristics are known to be affected by other compiler options.  Or it might be that your tests failed to detect this.  Whatever, assuming the compiler will always use stack allocation in a non-RECURSIVE procedure for unSAVEd variables is a pretty risky assumption, and one that I do not recommend.

Cheers,
--
................................Malcolm Cohen, Nihon NAG, Tokyo.