Renaming is definitely not recommended in the post, I should be more explicit. I was using the objcopy stuff to try to describe the effect of the interoperability functionality. In no way do I think there can be any sort of toolchain or program involving liberal usage of objcopy for anything in production.
As for the type bound procedures and CLASS entities, since the goal is really calling them from Python, it should be (is?) legal to have a wrapper function which takes in a type instance and executes the call. Actually, since such a function would require the size of the type, it is easier to pass a pointer to said type instance; the size of which is specified by the compiler and fixed. This is, from my understanding is the “Pointer to an Opaque Container” method described in the literature [1] and seems reasonable, if a bit clunky. I’ll be looking into it for a few compilers soon, but it certainly seems alright so far.
As far as them simply not being interoperable, in this approach they are called from the Fortran side only, with the C / Python coprocessor only receiving the results, so they don’t need to be interoperable in the same way say, c_double and double are. From a “binding generating” perspective (e.g. F2PY), as long as automated code can be written to mimic the effects of the underlying Fortran code that’s good enough.
[1] Pletzer, Alexander, Douglas McCune, Stefan Muszala, Srinath Vadlamani, and Scott Kruger. 2008. “Exposing Fortran Derived Types to C and Other Languages.” Computing in Science Engineering 10 (4): 86–92. Exposing Fortran Derived Types to C and Other Languages | IEEE Journals & Magazine | IEEE Xplore.