"Edit properties..." in Data module is fixed in r18002:
http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=18002

Concerning the option of having "Edit properties..." in every node selector, that requires that qMRMLNodeComboBox knows about the application, which it doesn't in qMRMLWidgets.
One way of fixing it is to create qSlicerNodeComboBox in QtGUI.
For RSNA ?

Agreed, it's not an RSNA priority. Just wanted to get this into the system.

To avoid the 'knowing about the application' issue, I think we need some kind of factory like mechanism - so that modules can register their ability to operate on or edit certain node types (much like file extensions or mime types get registered with a file browser). That way the qMRMLNodeComboBox can be kept generic.

I agree with the "modules can register their ability to operate on or edit certain node types". Right now it's a hack in qSlicerApplication.

Note to developer: some work has been done already to make room for qSlicerModuleManager to receive that work.
a) Modules should register their nodes in qSlicerModuleManager, and
b) qSlicerApplication::nodeModule should be moved into qSlicerModuleManager.

Icons for each node type could also be registered here as well. Or maybe in vtkMRMLApplicationLogic to be accessible from qMRMLWidgets (especially. qMRMLSceneModel::updateItemFromNode() which can give an icon to items in qMRMLNodeComboBox )

Additional request:
In the nodeTypeLabel() method of the node combo box, it calls GetTagByClassName on the mrml scene to generate the label. This can lead to not user friendly strings in the GUI since it's using the XML node tag defined by the MRML nodes. I'd like to see an additional method on vtkMRMLNode that can be called instead of GetNodeTagName, such as GetNodeLabelName that can return a human readable string for use in the GUI.

According to the discussion
https://www.assembla.com/spaces/slicerrt/wiki/20140225_Slicer_hangout_about_subject_hierarchy
the Edit properties feature will be provided by the subject hierarchy plugin mechanism

Subject hierarchy plugins expose an Edit properties feature that is to be implemented in every "role plugin" (see http://www.slicer.org/slicerWiki/index.php/Documentation/Labs/SubjectHierarchy#Plugin_types).
The plugins implemented in Slicer core (Volumes, Models, Markups) contain this feature and the future plugins handling other types also should. Suggestions for plugins are welcome (so far SceneViews was requested)

This issue has been fixed in two ways

• Edit properties provided by Subject Hierarchy
• A generic interface for editing node types (see also https://issues.slicer.org/view.php?id=2109 and https://github.com/Slicer/Slicer/commit/c031a49fa331d3b3bad87278f4bdfef8aa4407f6)