While I'm typing my next round of questions, and based on the feedback in this thread, here is the list of use-cases that I could gather.

1. Gain early access to experimental or unstable features
   (e.g. because they're working on a research prototype, or because
   the feature is valuable enough to them to forgo some stability)
2. Restrict the use of more complex features (e.g. for easier
   onboarding of new developers or as educators to teach a
   well-delimited subset of the language)
3. Restrict the use of novel features since the last established
   standard/report.
4. Restrict the use to features that they don't like (e.g. controversial
   features like RecordWildcard or ImplicitParameters)
5. Name/refer to a particular feature when talking/writing/searching
   about it.
6. Restrict the use of features which require support from outside
   the Haskell ecosystem that can't be taken for granted (I think this
   concerns only UnicodeSyntax)
7. As library authors, to signal which features the library actually
   uses, hence which version of GHC the library is compatible with.
8. Retain access to deprecated features to smooth out migration over
   the deprecation period.
9. Retain access to deprecated features indefinitely.
10. Change the default behaviour of (part of) the language
    (e.g. StrictData, I think some of the dependent Haskell work falls
    in this category, but I can't pinpoint an example)
11. Extend the language in a way that is not backward compatible
    (e.g. OverloadedList, probably some dependent Haskell things too)
12. Enable features whose mere presence has a performance impact
    (e.g. Template Haskell, and that's probably it)
13. CPP (this one is very unique isn't it?)

On Mon, 17 Apr 2023 at 09:02, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
(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