(sorry, it's been a busy week, next email thread comes out today, or tomorrow at the latest)

Joachim:
From a user-point of view, it seems you could possible merge 1, 4, 5,
6, 7 and 8 as “Developer wants access to features not on by default”.
The developer probably doesn’t really care _why_ the extension is not
on by default, they just want to use it when they want to use it :).

At the end of the day, an extension is either a feature that is off by default and can be turned on, or on by default and can be turned off. I don't think we've said much when we've reduced the users' behaviour to that level. So I wanted this list to be specifically about the why. And I think the users do care. GHC Proposals say “I want a new extension to support X”, I wanted to be as exhaustive as possible to then be able to try and then delineate the X-s that we intend language extensions to support.

On Fri, 7 Apr 2023 at 17:33, Chris Dornan <chris@chrisdornan.com> wrote:
As Joachim says, "Programmers use extensions to _refer_ to a particular feature  when talking/writing/searching about it."

I think this is generally important. The language reports provide the foundations for understanding the language and it is important to have a handle to describe the various departures from it -- at least until a new report around which near universal acceptance can be established. 

I would extend "2. Restrict the use of more complex features" to say "2. Restrict the use of _novel_ and more complex features".  I think many just want to say exactly how they are departing from Haskell 2010, whether those deltas are complex or otherwise.

Chris