I still have some reservations about a pointer dummy argument being associated with a nonpointer actual argument. I understand that this is just a shortcut within the subroutine for a target attribute on the dummy array, followed by a local pointer being assigned to that target. But that shortcut still has kind of a funny overall feel to it.
As explained in the original post, the reason the original code did not work was because it was an explicit shape dummy array, declared as a(n). That declaration means it must be contiguous. If the actual argument is not contiguous, then copy-in/copy-out argument association must occur. That eventually means that the pointer assignment is to that copy rather than to the original array, which I think is what was desired.
There are probably many ways for a compiler to make all that work, but I can imagine that the foobar2() routine alone cannot tell whether the actual argument was contiguous. It only sees the copy, which is contiguous. The calling routine foobar1() cannot necessarily tell that an illegal pointer assignment occurred within foobar2(). This simple case is an exception perhaps because the compiler can see both routines at the same time, but in the general case, when only the interface of the callee is available to the caller, it could not know that.
One wonders what kind of tests could be done by foobar1() to warn the user at run time that an undefined pointer is referenced. It knows that copy-in/copy-out was done, so it knows that something fishy might occur. It could look at the stack pointers used for that temporary copy, and after return it could look at that pointer to see if it points into that part of the stack. I guess this is the kind of test that nagfor is doing to catch this error. Presumably that part of the stack has been popped by the time p is referenced in the print statement. So in this case, I think it would be possible for foobar1() to detect the illegal reference. However, in more general cases, say where the pointer is just passed back to its caller, or maybe the stack is pushed for some other reason before p is referenced, then a runtime test might return a false negative.
There is also the situation where the explicit shape dummy a(n) is associated with a contiguous actual argument. In this case, the pointer assignment points to the right actual array, but upon return, the pointer is still undefined. To the programmer, this would appear to work correctly, but it would still be processor dependent, meaning it is not defined by the standard to work as expected.
One can imagine other possible problem situations too. Suppose the dummy array is assumed shape with target and contiguous attributes (or the shortcut, with contiguous and pointer attributes). I think this would also trigger copy-in/copy-out, so the pointer assignment would not work in this case either.
So the problem all along was that explciit shape declaration. If that is eliminated, then the pointer assignment works as expected.