As for compiling Famix to programming languages, this is a very different story.
Currently the way it works is that we program things in Pharo, add the appropriate pragmas to the Pharo methods, and then generate Famix from the Pharo classes.
What I would like to have is more top-down: we generate everything in Famix (will need a bit of tooling here), and then we generate Pharo code automatically.

Done that way, the discussion about trait and inheritance can be eliminated because actually, one can generate a flat set of Pharo classes where all inheritance has been inlined.
In some sense, it is again similar to current implementation of Traits in Pharo where the Traits methods are compiled inside the Pharo class.

So again it will be kind of using traits again.

I disagree. We keep a 1-to-1 mapping to Pharo. This is critical because we are using Pharo as the execution language and we do not want to deal with two model abstractions. Of course, we should also build tools, such as the MetaBrowser that make it easier for us to handle the meta-descriptions, but in the end we want to keep a clear mapping to Pharo code. This will save us a ton of trouble down the road.

Given that Traits are already supported in the execution language (Pharo), we can directly use this 1-to-1 mapping without any problems. So, we will not rely on generation at all. The same as it is now. And we put in place tests that check the meta-descriptions.

Generation only looks cheap, but as soon as you want to manipulate anything at the lower level, it becomes highly expensive. We managed to keep away from this and it payed off until now. I insist on this point :).