(j3.2006) Type compatibility for nonpolymorphic objects

[Van Snyder]

Would it be possible and reasonable to extend the definition of type 
compatibility for nonpolymorphic objects to be the same as for 
polymorphic ones?  It would be a bit of work, but would there be 
technical inconsistencies that render the project impossible?  It would 
indirectly constrain implementation methods for extensible types so that 
extension type -> base type -> class argument passing works, but I 
suspect the constraint would be to methods that everybody already uses, 
i.e., components of extension types come after components of the base type.

This question arose when a colleague was using a subroutine that had a 
dummy function.  The dummy function is passed a derived-type dummy 
argument of the subroutine.  My colleague tried to extend the type of 
the argument of the subroutine, and then make the dummy argument of the 
actual function corresponding to the dummy function polymorphic.  
Because the dummy argument of the subroutine was not polymorphic, the 
actual argument of an extension of its type was not compatible.  My 
colleague doesn't own the subroutine; all he has is a library of .o 
files and a collection of .mod files.  He had to track down the owner of 
the subroutine and request that the dummy argument be made polymorphic.  
The owner didn't want to do that because he has a customer base that 
includes clients who do not yet have access to compilers that support 
polymorphism.  He was eventually convinced, at extra cost, to provide a 
version having a polymorphic argument.  Now he has to maintain two 
versions until all of his customers have compilers that support 
polymorphism.

program p
  use m

  type, extends(t) :: t1
    blah, blah, blah
  end type t1

  type(t1) :: v

  call s ( v, f ) ! OOPS!

contains

  function f ( a )
    class (t) :: a
    select type ( a )
    class is ( t1 )
       ! access to blah, blah, blah allowed here
    end select
  end function f

end program p

module m
    type :: t
      ....
contains
  subroutine s ( b, g )
    type ( t ) :: b
    interface
      function g ( a )
        type ( t ) :: a
      end function g
    end interface
    .... g ( b ) .... ! invoke the user's function
  end subroutine s
end module m