The only reasonable thing to do here is to include MPI_INTEGER and other Fortran datatype enumerations in the meaning of Fortran bindings and not define them in the absence of a Fortran compiler. Any other solution is unreliable, ill-defined and going to lead to sadness.
More below.
Alternatively, the Fortran processes can use ISO_C_BINDING and convert to C datatypes before sending. Since we have standardized the use of Fortran 2008 in MPI-3, there is absolutely no reason why this should not be the recommended practice, because it is completely reliable and well-defined.
> ARGUMENTS FOR A CHANGE
> ======================
>
> B1. Setting MPI_INTEGER (and friends) to MPI_DATATYPE_NULL -- which will cause a run-time MPI exception -- is somewhat anti-social behavior (and potentially confusing to the user).
See above.
> B2. An MPI implementation can *assume* but can't *know* what the size/representation of Fortran datatypes are unless there's a Fortran compiler with which to test.
You know what happens when you assume, right?
What possible value does it serve to guess? We create a situation where sometimes it works and sometimes MPI programs crash and burn? While we are at it, let's add MPI_Barrier_sometimes(double randomness_factor)...
> B3. A3 is a somewhat sketchy claim. It's obviously possible and valid, but fairly uncommon to have multiple MPI implementation installations involved in a single execution of an MPI application.
It is valid to have multiple implementations, but not valid to expect processes that use a Fortran-oblivious MPI library to understand Fortran data.