[Perhaps there needs to be a "MDR Explorer"
subcomponent?]

Use case: Let's say I want to examine the "type"
reference of every TypedElement. To do so, I have
to manually set the look to "Reflective View" for
every single TypedElement's node that I want to
look at, via the context menu's "View As |
Reflective View" action. For example, if I want to
examine 15 attribute's types, I have to issue the
"reflective view" command 15 times. I believe that
it should be much more convenient than that.

Possible solutions:

(a) The user could set the look to "reflective" on
the some high-level node. Then, the child nodes of
this node would default to the "reflective" look.
Advantages: This should probably be the way looks
should work by default anway (in MDR at least).
Disadvantages: Mixing the aggregate and
non-aggregate nodes in the explorer is confusing.
Doubles the amount of nesting (one node for the
object's node, one element for the reference's node).

(b) Add the references to the property sheet along
with the attributes. Advantages: Attributes and
References are a lot alike, so they should have
similar UI; some reference-like functionality in
the property sheet is necesary anyway for
RefObject-typed (composite) attributes.
Disadvantages: The property sheet component
doesn't have a good UI for multi-valued
properties, and many references are multi-valued
(actually, attributes can be too).

(c) Implement something analogous to the
"JavaView" module contributed by Andrew Tver
(http://www.netbeans.org/servlets/ReadMsg?msgId=342867&listName=nbdev).
Basically, the MDR Explorer window would show just
the objects, nested according to their aggregation
links. The JavaView-like window would then show
all of the references and attributes of the node
selected in the MDR Explorer window, in a JTree.
In this case, there wouldn't be any need to use
the standard NetBeans property sheet. Advantages:
I like it and it makes sense to me. Disadvantages:
it isn't the way that most NetBeans modules seem
to work.

After using JavaView for a while, and after using
the same type of thing built into Oracle
JDeveloper at work, I think that option C is the
best UI.