You wrote:

> [lots of good points snipped]
>
> 1. For want of a better term, GNU/Linux. The original POSIX/UNIX
> Operating System with Linux as the OS kernel, Glibc (usually) as the C
> Library, a mix of BSD and GNU userland, the GNU toolchain and X for
> workstations along with one of the many Desktop Environments.
>
> [...]
>
> Seen this way, what we want is clear. We want what we wanted from the
> beginning, option #1. Simple, easy to articulate and pretty easy to
> decide to include/exclude features based on the criteria. And when it
> gets time to organize beyond some folks in an IRC channel, some thought
> into codifying exactly what the project is and is not trying to
> accomplish would be a good idea.

So I really like this line of thinking - trying to articulate
the possible ideals/values of the distribution, so that people
can work to a common purpose, and that those who have different
views don't waste their time and rather contribute to some other
project.

So possibly candidate points related to this:

- having established/simple/stable/documented interfaces between components,
so that arbitrary components can be substituted - that there
is a choice of components. I think the posix syscall API is
probably the best example of this - there are multiple free
kernels which can provide it (linux, various BSDs, hurd)
and lots of free application code which uses it. But there
are other examples - we have multiple shell implementations
providing similar command lines, a stable file-system
hierarchy, multiple mail clients understanding the same
mbox/maildir formats, X11 servers by multiple vendors, etc.

It is the change to intricate and fast-moving interfaces,
as exemplified by systemd (but also other projects) is
concerning, as this means discarding lots of well written
and reliable code, almost just for the sake of change
(famously gnome).

And maybe even:

- minimising the size and dependency graph of the essential
system. I have had friends worry that the base Debian seems
to have been growing each year so that it doesn't fit onto
small/embedded systems anymore. For anybody who has tried
to build a distribution from scratch particularly for a
new architecture or just platform (a really instructive
exercise), a small core lets one get to a running system
quickly (the first big win), and then a self-hosting system
(the real win). Beyond these points the nonessential stuff
can depend on arbitrary things, but getting the core up
and running is critical for a free distribution to support
new/unconventional platforms, or to serve as base for other
distributions or appliances. The downside is that somebody's
favourite scripting language isn't essential - but it is
still there ... it just not used in the core.

Maybe visualise this as a well-formed tree, with the kernel, libc,
compiler, shell and shell utilities forming the trunk and then only
at some meters above ground things branching into complex
dependencies ...

I suppose there might be other goals related to security, which
could be interesting, but that might be a discussion for a later date.
Anyway, thanks for reading this far

regards

marc