My real question is this:

• Who “owns” (as in: takes responsibility for) the GHC API?

I guess one thing very important to me is that the architecture of GHC and it's public interfaces will always be deeply intertwined; or put a different way, efforts to manager the public interface as a thin veneer over a big black box will not work.

• What is a good public API?  Where is it written down?

This I agree is important to discuss. I do agree with Moritz that a lot of this stuff can be evolved, but the general direction can be still be discussed. For example, the basic objects I offered are a *huge* departure from what we have today, and any huge change should be discussed up front a bit.

• What should GHC’s extensibility interface be like?   Plugins and all that.  What is a good design for (say) extensible interface files?  What “hooks” should the GHC API afford?  This is more than just “what arguments should this function take”… it’s a matter of fundamental design.   But design questions like this belong in the GHC-API world (not the core GHC world) because they are all about extension points.
• What is a good design for the plugins story more generally?

I've mentioned this before but I think plugins/hooks/etc. are a terrible way to reuse GHC for other purposes, and exist as a symptom of the rest of the compiler not being at all modular. It's fine that we continue to support them in the short term, but in the long term I'd really like to have a plan to obviate them completely. (One can search "composition over configuration" and variations on that slogan to find much ink has been spilled on this general principle.)

John