unstable, metastable, stable
It occurs to me that many of my systems would benefit
from splitting unstable into two separate sections,
where each package maintainer specifies a flag that
determines which section it should be in.
By default, packages continue to be in "unstable" and "stable",
but a subset will progressively be in "metastable" and "stable".
The definition of "metastable" is those packages which,
even if full of bugs, are unable to cause a denial of
service to users other than the one which invoked it.
I'd assume that "xclock" would be eligible, for example.
In themselves, these packages cannot make an otherwise
stable system become unstable, but they can make the
user who invokes one of them intensely regret it, and
the user's personal account may be 'unstable' afterwards.
I suspect most Debian packages could be metastable,
with only a small core of 'dangerous' choices continuing
to remain in unstable. For a start, probably most
packages that contain suid root executables.
The benefit of this approach is that it doesn't increase
the server size, yet does give users another choice.
Packages in metastable will probably get a lot more
exposure and testing before they make it into stable.