Well, I'm not an OpenMP ARB member, so I can only guess... maybe someone else will be able to provide better answers...
I think the main problem has been about implementation and performance penalties incurred in so many "implied flushes" given by
a reference that reads the value of an object with a volatile-qualified type
behaves as if there were a flush operation on that object at the previous sequence point,
while a reference that modifies the value of an object with a volatile-qualified type
behaves as if there were a flush operation on that object at the next sequence point.
(Spec. 2.5, p. 12, about C/C++ volatile) besides I don't understand and I did not find what a "sequence point" exactly is... Other reasons: a) Fortran volatile had different requirements/definitions for compilers (I don't know which ones, however, from a computer language point of view I look them as equal/similar, but I don't know a lot about Fortran, and I do know Fortran has a lot of details...) , b) They do not want to have special definitions for language specific cases/definitions (or Fortran "object" attributes, according to the Fortran standard/s). Looking at the Fortran 03 and 08 standards, the note
The Fortran processor should use the most recent definition of a volatile object when a value
is required. Likewise, it should make the most recent Fortran definition available. It is the
programmer’s responsibility to manage the interactions with the non-Fortran processes.
(Note 5.21 in F03, and Note 5.25 in F08) I tend to agree with you in some "overriding behavior", but I do not know if there is some "elegant" way of solving it... unless the Spec "goes back" to 2.5 treatment of volatile data...
Remember: I'm just guessing...