I realise that such a system would probably scare the hell out of RMS, but he should know well enough that any obfuscatory changes are easily undone. In some ways, it's like the war between software protections and crackers - once the crackers developed tools to analyse and automatically bypass any local serial-number type protections, they solved the problem generally and DRM was forced to go online. I'd be interested to see what RMS would try if faced with such a solution...
One problem here is that RMS is not a C++ programmer (not an entirely unwise decision!), the languages he programs in, to the extent he does anymore, don't require this sort of thing, and apparently doesn't appreciate how this is a deal breaker for modern C++ programming. Or doesn't care, and how that's decreasing GCC mindshare as well.
Because of this policy with GCC, 99.999% plus of the the academic mind share is with LLVM, and the only thing keeping it from taking over is it's relative paucity of backends.
If it were so easy it would have happened by now. One can only conclude gcc and its stewardship have no real desire to allow for such a thing to occur at all.
Which means llvm will likely be the future for being able to handle large complex code bases and interactivity with editors like emacs or vim, or whatever else. Why we have to reparse c/c++ in every editor alive when the compiler already does such things and would just need to dump out the information needed to understand it is beyond me.
I only see 2 solutions to this situation. First is gcc gets left behind as a backwater compiler that won't interact with the real world due to religious reasons. Second is it gets forked and like ecgs before it, the fork becomes the canonical version (likely ignored by the gnu/fsf folks as being a heathen fork or whatever).
It's a pity because it is quite an enjoyable IDE to use every single day for my C++ work (I'm on 6.1.1, doesn't crash unlike the 6.0 series), but missing a feature like that stinks.
Not that I've ever had need to use it so far, but still, it is a pity.
Oh, if only they'd ignore the heathen fork of one of their marque projects. Not going to happen with EMACS, 99+% of its greatness is due to RMS by universal acclimation as of the very early '80s.
The debate hinges on a very subtle point: GCC does not commit to keeping the plugin API nor the AST structure stable between releases, making it difficult to maintain any software that relies on a specific shape of the plugin API or the ASTs.