I'm a bit confused by drill down ...

This is an old thread - I'm not trying to revive it, but just in case anyone is searching the forum to find if anyone has asked a similar question about nested diagrams & any resource they may produce (whether represented by a terminal object or not) - a simple answer is "proxies are not required."

A longer answer:

I asked a similar though not identical question of Jury Shortki in an email (I hadn't yet registered on the forum otherwise I would have asked it here). Here is my question as I worded it: "I am looking for a good example diagram that better illustrates creating nested diagrams - in particular, how the terminal object in the nested diagram relates back to the parent diagram."

And here is what he wrote back to me: "The encapsulation principle operates in the application - the parent diagram 'does not know' the features of the nested structure. For the parent chart, only the nested state is important."

Note that the above refers to execution only: all that the parent diagram requires of a nested diagram is that it be 100% completed for the parent diagram to then resume with its next execution step. (Not sure if I phrased that correctly, but hope it's close).

Now, as to how exactly the achieved goal (resource created) belonging to a nested diagram is represented visually - well, this seems to be user choice: you can have the nested diagram terminate in a process or a resource object as you wish; it's up to you. For that matter you can insert a resource into the parent diagram immediately after the nested diagram, representing the goal of the nested diagram; again, the application won't care. It's more a matter of how you want to show things. Probably what matters most is that you are consistent in how you represent such things, so as not to confuse the reader of the diagram (which might be someone else, or might be your future self).