In that case the MERL in Object2 to display the Name of Graph1 is:

There's an example of this in the Digital Watch project, where the LogicalWatch objects have decompositions to WatchApplication graphs. Since we want the name of a LogicalWatch object to be the name of its decomposition graph, we don't need any properties in the LogicalWatch object itself. Instead, we set the LogicalWatch object type to use an identifier generator like the above code. Similarly, the symbol for LogicalWatch can use a text element with a similar generator (or, indeed, just id).

I have a new graph1. I have created an object (say object1 and it has a property name). I have a made a new graph2 for decomposition of Object1. I have created another Object (say Object2) in Graph2. I want to display the name of Object1 in Object2. 

Is Object1's name the same as Graph2's name, and creating an Object1 means you should also create the corresponding decomposition, Graph2? If so, there is a nice solution: what I described in my previous answer, plus that Object1's symbol has a text element with a generator id;1. The ;1 means to get the information not from the current element in MERL, but from one stack level further out. A symbol generator is called with the context of the graph then the object, so id;1 here will be the name of Graph2, and hence the name of Object1.

If that doesn't work, then you probably need to look a bit more at what you actually need in the modelling language and possible code generators. Certainly from the point of view of a code generator there isn't a need for Object2 to have a link to Object1 - your generator will have started from the top level, so it can simply get the name from the context stack with id;2 (assuming a stack of Graph1, Object1, Graph2, Object2), or then if it feels easier you could store the name of Object1 in a variable and use it later in Object2. The question then is more that why does the modeller need to see the name of Object1 in Object2 in Graph2. Generally that shouldn't be necessary: if I'm writing a function, I don't need (or want) to know the name of the calling function. We can have black box, grey box or white box components, with the difference as to whether the caller can see inside the callee, but never can the callee see inside the caller. 

I'd encourage you to think this through and aim for good modularization practices. I've seen too many bad examples to stay quiet on this :). Of course MERL is able to search through all graphs to find Object1:

But that's a different cost performance-wise as the number of graphs and objects grow. You can improve it somewhat by filtering to just graphs of the right type and avoiding performing the default sort on them:

If you want a computer science explanation: the world is not a tree. In a tree every element has one parent (or none, for the root). The world isn't like that, so MetaEdit+ isn't like that: an element can have more than one parent (or more accurately, be referred to from more than one place). Even in a normal computer science tree data structure, where there is a unique parent, there is no way to navigate from an element to its parent. To do that, you need a different data structure: a doubly-linked tree. By doubling links, as some meta-metamodels do, you create high coupling and prevent modularization. Tools (and languages) based on those meta-metamodels have trouble scaling, in terms of modeller comprehension, tool performance, and productivity increase.

Think of a graph as a component or a function. A component or function shouldn't know who is using it. By not knowing, it becomes reusable - it has no link to or entanglement with its 'user', so it can be freely applied elsewhere.