It does sound like an interesting approach, but at this point it is a bit unclear what would be the overall structure of the solution.
Since we already have the Xtext infrastructure in place, it seems like the most productive approach is to develop this, rather than say start from scratch using some other parsing technology.
I think we can do something like what Osate2/AADL does. AADL (Architecture Analysis & Design Language), for those that might not be familiar with it, is a language not unlike UML-RT, and consists of a top-level "core" or "parent" language to describe components. Components' descriptions may have so-called "annex subclauses". These are subclauses written in some "Annex Sublanguage". To the user AADL code with "annexes" looks like this:
process C
features
u : out data port;
annex MyLanguage {** ... **}
end X;
In their case the {** and **} are delimiters for everything in the sub-language.
The Xtext parser delegates the parsing of such sub-clauses to an external user-provided parser through an extension point. The result is seamless integration, with syntax highlighting, formatting, outline, code-completion, etc.
The requirement is that the user-defined parser must return an Ecore object implementing a particular interface.
So we could parse external languages including C++ if the parser conforms to that contract.
The problem that remains is that, as I mentioned earlier, there are no C++ parsers that have an Ecore meta-model, which means we have to create one, and a parser that produces that representation. In that case, Xtext is the obvious choice, but again it's unlikely to be able to parse all of C++.
However, I don't see a better alternative right now.