In particular, I have had transfer of pointer components cause problems
with garbage collection. I don't do that kind of thing any more. My
experiences with it were too painful. It is also some of the stuff that
I can see that the f2003 object oriented features would help make
cleaner. For the interim, I used other methods, that don't seem as
elegant or flexible, but did the job for my application. Anyway...

I had a derived type with a pointer component. Actualy, multiple
different derived types, each with different pointer components. It is
determined at run-time which type is being used. In order to fake what I
know know of as polymorphism (though I hadn't heard of the term then), I
used transfer to store the bits in storage of a "neutral" type (I used
an array of integers). The higher level code didn't then need to know
the details of the different lower-level types. The bits were later
transferred back into the appropriate type when it was needed to use
them. But... sometimes the compiler's garbage collection would run while
the bits were stored in the "neutral" type. The pointer targets looked
like allocated memory that had no current pointers to it. So it got
garbage collected. When I later transfered the bits back to the right
type, the targets were gone.

In some senses, I'm not sure this is as good an example of problems as
the allocatable one. But this is one that I actually got bit (um, pun
not intended, or even noticed until I reread this) by in the early 90's.
It is what made me start thinking about the possibility of cases where
just naively copying the bits might not have the effect of copying all
the information correctly. One example that occurred to me (but I don't
think I've seen) would be relative addressing of pointers. If you have
relative addressing, then copying the same bits to another location
doesn't preserve their meaning.