An important feature of F90, and the one most responsible for Fortran's survival as a mainstream language, is that all F77-compliant programs are automatically F90-compliant programs. This is something that many F90 proponents seem to want to wipe out in future versions, and you should protest vigorously. Refusing to buy these products is an alternate strategy, but it is better to have a useful F2000 standard than to have two standards, one "theoretical" and one "practical". This situation sort of already exists due to the continued use of DEC extensions to Fortran instead of the F90 standard syntax. It's a real shame that DEC and the F90 committee could not agree to use the same extensions to F77!
The single most important issue to my mind is that of storage association. Many language "purists" are committed to remove storage association from the Fortran language definition. This has traditionally been one of Fortran's strengths. Storage association refers to things like EQUIVALENCE statements or COMMON blocks. These have been used heavily in data-acquisition and analysis programs to exploit knowledge of data format at the hardware level and thus make the code run much faster. The proposed changes to the standard, touted as "safety features" which will make the Fortran language more consistent and eliminate "dangerous programming practices", will remove this capability. For many applications, the proposed replacement functionality is fine, but not for hardware-oriented programming.
Another important issue is that of this replacement functionality. F90 has two ways of doing many of the things it can do. One way is the F77 way, and the other way is "the modern way". There are rumblings about trying to remove this duplication (i.e. the F77 ways.) Already, most F90 compilers I've seen have dropped support for common-practice F77 extensions which have the same functionality as F90 features. These feature removals will sooner or later force (perhaps extensive) rewrites of older codes. When storage association becomes obsolete, even more of this older code will break. Every routine I've ever seen for computing Clebsch-Gordan coefficients falls into this latter category.
Making successors of F90 "pure, clean, and modern" is a task that is much better addressed by simply using one of the existing "pure, clean, and modern" languages, or by perhaps creating a new one (e.g. the new "ELF" or "F" dialects of Fortran, which make no claims to supporting F77 users or programs.) A language which purports to be a marriage/compromise between a system which provides backwards compatibility for decades worth of working software, and a system which encompasses only elegant, state-of-the-art techniques, is bound to be unsatisfactory in both departments. F90 is a good compromise, since one is never forced to give up what is already working.