Hi Christian,
thanks a lot for this experiment and the summary you sent!
Being involved in the textual modeling effort and in the EMF Compare customization part, I do think it indeed is worthwhile to have an EMF-based facade.
For textual modeling, as you wrote, an EMF-based facade would help integrating Xtext with the custom UML-RT elements. We'd have to solve the bootstrapping issue, but aside from that, this would enable us to define the grammar against a the "facade metamodel" (that is the extended UML.ecore of your facade) and, in memory, build a native UML-RT model with all its stereotype applications etc. Xtext wouldn't have to be aware of how UML-RT concepts are actually mapped onto raw UML concepts.
The other use case is the EMF Compare customization. Currently we achieve all the integration by teaching EMF Compare the specifics of UML-RT. This is fine but it also means reverse engineering and re-implementing everything that is already implemented in some way in Papyrus-RT. An alternative approach that I started thinking about more and more a couple of weeks ago is to let EMF Compare work on with an UML-RT-specific facade instead of the pure UML model. Of course, we'd require the facade to be a "normal" metamodel API/implementation (essentially an extended UML.ecore) that can be instantiated from the plain UML model. This way, all the raw specifics of UML-RT could be hidden from EMF Compare (and its users) and let the facade handle them. This will enable a larger degree of reuse among Papyrus-RT tooling and its EMF Compare integration.
So in summary, the beauty of an EMF-based facade is that it may facilitate the direct integration of EMF technologies (Xtext, EMF Compare, and probably several more) without the need of intrusive customizations of those technologies, as it is today.
So far my two cents on this topic.
Thanks a lot and best wishes,
Philip