How should we treat changes to the GHC API?

[Moritz Angermann]

I think this is the core issue here:
> 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.
I don't think we know this apriori, and it will be discovered over
time as more and more producers and consumers start making use of it.
Is the current design the best one? I have my doubts, is it a first
approximation? I think so.

I think these features are more discovered than designed. It's easier
to iterate over concrete implementations in this area than over
abstract ideas.

I would propose having some EXPERIMENTAL markers for these kinds of features.

I do agree that a group of people who feel strongly about this should
be listed in the CODEOWNERS file for the respective parts of the
codebase, and take an active part in code review.