(j3.2006) 09-211 is unnecessary

[Van Snyder]

Paper 09-211 proposes to add a construct

ASYNCHRONOUS buffer
...
ASYNC_BLOCK (buffer)
    CALL MPI_IRecv(buffer,...,request,...) ! request receive into buffer
    ...! do other work while the buffer transfer in progress
    CALL MPI_Wait(request,...)        ! wait for communication to finish
    ...
    call foo(buffer)                       ! do work with buffer
END ASYNC_BLOCK
...

This is unnecessary now that we have the BLOCK construct.  Instead the
program should use

BLOCK
    ASYNCHRONOUS :: buffer
    CALL MPI_IRecv(buffer,...,request,...) ! request receive into buffer
    ...! do other work while the buffer transfer in progress
    CALL MPI_Wait(request,...)        ! wait for communication to finish
    ...
    call foo(buffer)                       ! do work with buffer
END BLOCK

This is unrelated to MPI.  The potential for the problem described in
09-211 to occur is also present in

    CALL A(buffer,...,request,...) ! request READ into buffer
    ...! do other work while the buffer transfer in progress
    CALL B(request,...)        ! wait for READ to finish
    ...
    call foo(buffer)                       ! do work with buffer

if A were to execute an asynchronous READ statement and B were to
execute a WAIT statement.

The solution is the same for the Fortran problem and the MPI problem:
The compiler can't move anything involving a variable with the
ASYNCHRONOUS attribute across a procedure reference, and it it has the
POINTER or TARGET attribute it also can't move anything involving
pointers with the same type and kind (and just about any rank if it's
rank 1 or contiguous) across a procedure reference, and if it's a common
variable or a public module variable it can't reorder procedure
references, and it can't reorder references to internal procedures,
and ....

No new bells, whistles, knobs, levers or gears are needed.