d = transfer(e,d)
  now use transfer(d,e)

This is for a case where D is of a "benign" type where the assignment
operator doesn't do anything "odd".

So do

  d = transfer(e,d)
  call sub(transfer(d,ee),e)

where ee is another vairiable of the same type as e. I probably don't
even need it, but I use it to remove any question that the first
argument might have any reference to e. Now in the subroutine

  subroutine sub(ee,e)
  ...

I can imagine a fair chance that the allocatable components of e and ee
have managed to get "associated". Well, not as defined by the standard
because it doesn't have any concept like that for allocatables. But if
you change the value of the allocatable component of e, that's likely to
also change the value of the component of ee. Deallocating e could have
other more "interesting" results such as the component of e pointing to
storage that is used for some random other thing. I don't see that this
code violates any of the rules of the standard. In particular, the
actual arguments aren't associated in any way acknowledged by the
standard, so the prohibitions against changing the values of the dummies
don't apply. You can't directly change the value of the first dummy
because its actual is an expression, but you can change the value of the
second.

That's just a pretty much off-the-top-of-my head example. It is slightly
indirect because I did keep running into bars (some of the same ones you
mentioned), but I methodically worked around each one.

Once you have a single "hole" like this, you can open up many others.