I'm working on a plugin architecture for GCC. The idea is to provide an interface through which shared libraries can contribute components (plugins) that can cooperate to deliver services to GCC.
Each plugin is given a simple lifecycle model and is allowed to determine its initialisation parameters from a free form XML specification - allowing for the initialisation complexity suitable for scripting, for example.
Plugins communicate with each other via extension points which allow the plugins to share behaviours and listen to events, etc.
The idea is that rather than having a plethora of different GCC branches, we may get a simpler, smaller GCC into which code libraries are selected at runtime, allowing GCC modifications to live outside of GCC. Presently, (I think, from what little I know:) ) getting code accepted in the mainline GCC is not easy. A plugin architecture would make this mostly unneccessary for many projects. Users could try out new plugins without having to install a whole new suite and could pick and choose plugins that suit them in much the same way that nearly every Eclipse user has their own set of favourite plugins.
Being a scripted, GCC data structures were presented in an object oriented way without having to concern oneself with the complexities of memory management and odd macros here, there and everywhere. One could make small modifications in a few easy lines of script without having to dig deep into GCC to do it, so it lowered the bar to getting involved in GCC.