> There's other benefits like cross linking with #123 format, @mentions,
> labels, thread state (open/closed/locked), diff view for pull
> requests, etc, etc, things that email doesn't have. :)

Mail has all of these, except labels and thread state, and I think
that's desirable.  Keeping an issue tracker up to date is time consuming
and ultimately impossible to get right.  Case in point: Nixpkgs' issue
tracker.

As for your other points:

- You can include URLs to mailing list archives, or even just message
  IDs, which you can look up in public-inbox[1].
- Mentions are called Cc in email.
- Diffs are how changes are generally communicated over email[2].

[1]: https://spectrum-os.org/lists/archives/
[2]: e.g.
     https://spectrum-os.org/lists/archives/spectrum-devel/87eewn9g8q.fsf@alyssa.is/T/#iZ2e.:..:20191229170906.362205-1-nicoo::40debian.org:0start-vm.nix

Meanwhile, there are lots of advantages to email.  Here are some (but
not all) of them:

- There are lots of different email clients available, so people can use
  whichever one meets their needs.  GitHub has to cater for the novice
  and advanced users all at once, whereas with email these use cases can
  be handled by different clients well suited to their specific tasks.
  For example, I'm writing this email from Emacs, which is a much more
  pleasant composition interface than a text field in a web browser, and
  this makes a big difference when you deal with a lot of different
  threads.  And if you prefer writing in a text area in a web browser,
  you can do that too.
  
- Email has proper threading, not flat conversations like GitHub has.
  Ever tried to follow a NixOS RFC, or even worse, a Rust one?  Because
  of its support for proper arbitrary-depth threading, long, detailed
  conversations are much easier to follow over email.

- I don't need to supply Git hosting to every potential contributor, and
  nor do they have to find their own, because no hosting is required so
  send a patch over email.  It's also a much easier flow to teach
  somebody who's new to Git.  You don't need to know what a branch is,
  what a fork is, or to sign up for an account anywhere.

> The attached screenshot shows how email makes things more difficult.
> It's would be PITA to configure all my devices for this list.

Ah, yes, this is unfortunate.  Thank you for raising it.

Rejecting HTML mail was a decision I made for a few reasons:

- public-inbox doesn't support it.
- Patches would be mangled if pasted into an HTML-generating composer.
- It's been the source of several major security bugs in mail clients,
  because it's such a complex format.

Now, given it would be good for Spectrum if people who did not know or
care about the difference between HTML and plain text mail were able to
ask questions and get support, I do think that probably I should relax
this for the discuss@ list (but not devel@, where not mangling patches
is important, and people can be expected to be a bit more technical).
discuss@ could just discard HTML parts, and that would still prevent
exposing other people to HTML mail, without forcing people to manually
disable it in their clients.

But, despite all of its many advantages, I know there are people who for
whatever reason don't want to use email, and that's why we have a
Hyperkitty.  If you prefer reading and writing messages in a web
browser, that's what Hyperkitty is there for.  You don't have to use a
mail client if you don't want to.  Unlike, with GitHub/GitLab, nobody is
forced to use any particular way of interacting with the discussions.
That's one of the best things about mailing lists. ;)

> Let me try hyperkitty; it may be the only way for me to use the list.

I hope it works well for you.  If there's anything I have configured
poorly about it, please let me know and I'll try to make it better if I
can.