Toward a "modern" Emacs

> > that someone will have to show how those changes will be an overall
> improvement _for the existing team_
>
> Totally agreed - as long the existing team doesn't "live under a rock",
> doesn't place non-technical objectives too far above technical ones and can
> generally listen to unusual perspectives.

But who does that? I'm not a member of Emacs core team and never sent
any patches but I'm glad they think about the future, I'd like to see
how Emacs evolves in the next decades. I also described how Emacs
fills all of my needs as a programmer in year 2020, mentioned Emacs SE
(I forgot r/emacs) and stated that there are many other projects that
use e-email and that you should know how to use it. You somehow
focused on that e-mail thing and started convincing me that it's very
very bad and should not be used. Nobody "lives under the rock" here.

> Otherwise it would just be a lost cause it would be better to either
> fork or look for alternatives and not just for tooling reasons.

Emacs has been forked multiple times, and it will be forked multiple
other times if there is a need. For me, making it work on Wayland
without using XWayland is now one of the most important things to
do. I'd gladly start using Wayland on the daily basis without any
leftovers from X.

> Another option when you can afford it and when the size of the project
> justifies it is to "fragment and bridge" the tooling, this is what happens
> for the kernel for instance.

Emacs is, however, a much smaller project compared to kernel
(actually, most OS projects are smaller than kernel). It's also not as
critical and there are not so many eyeballs looking at it.