To resolve this kind of no-win argument, you have to solve the
root problem.
You cannot use an unstable version of D as a stable version, for
obvious reasons, each new stable release of D "stable" appears to
be a new unstable release of D.
It won't work to simply lock down D into only a stable version.
Doing that will piss off a lot of people who want to see new
breaking improvements implemented and released for use, and not 5
years later either, but a lot sooner.
Here's a simple example of a possible real solution for Phobos,
for sake of discussion I'm assuming DMD will be released under a
major.minor.revision numbering system, with stable and unstable
branches.
1) Assign Phobos it's own independent major.minor.revision number
with the major number locked in with the corresponding compatible
major DMD number. That way, users will know what Phobos version
is compatible with what DMD version.
2) Include multiple backwards compatible versions of Phobos with
each DMD release stored in a way that allows versions of Phobos
to be selectable by the D programmer.
I know that there are plenty of challenges to overcome wrt
changing the way D is being developed and released, but to try
and develop D using only one version for both stable and unstable
is simply not going to work. It also will not work to lock down D
and prevent it from improving in breaking ways overthe next 5
years (or whatever).
--rt
