The caching policy assumes that all model elements are created/deleted via the new/delete keywords of EOL (which eventually delegate to the createInstance/deleteElement methods of  - you can see how caches are maintained there). When attaching new elements directly to the underlying resource, caches don't get updated accordingly, which causes the behaviour you're encountering. Is there any way you could break down your transformation into 2 steps (one for the cloning bit and one for the actual transformation) and then use the Epsilon ANT tasks to run these sequentially?
I of course could split the transformtion into more steps, but it would enlarge the maintenance for metamodel updates or extensions, since I would have to clone manually.
Sure I could add an intermediate cloned model (created by automatically ecore) and transform this, but in my case cloning and the real transformation are not sequentially applicable but have to be interleaved (because of recursive structures with dependencies).
Wouldn't it be easier to more generally immitate the cloning process in EOL directly, without using the emfTool.ecoreUtil (for the special case of EMF models)?
I am facing a similar dilemma. I am thinking about a Flock + ETL solution. This might be helpful with your interleaved process. In my case most elements can be copied and slightly modified with Flock. But some of the elements require a more complex transformation. To make it more interesting I wished some of the attributes of a type could be copied and the rest modified... going crazy!
Horacio Hoyos Rodriguez
University Of York