Hi folks,

after having used envy for six years and Store for one I also feel 
obliged ;-)
to make a suggestion.

I would like to have a model with packages and package versions. That 
is it.
I think the difference to the package / configuration proposal is, that 
in my
suggestion the code can be stored in package versions,
which _can_ refer to other versioned entities.
But also one can try to load the newest possible configuration of a 
package.
This just tries to load all the newest versions of it and of all its 
prerequisites.
If that works, fine, you can just store that as a new version.

Here again that boring SmaCC-Development example to illustrate
some possible usage:

Package(SmaCC-Development) >> versions
	-> #(
		PackageVersion(SmaCC-Development 1.2)
		PackageVersion(SmaCC-Development 1.1))

PackageVersion(SmaCC-Development 1.2) >> prerequisiteVersions
	-> #(
		PackageVersion(SmaCC-Runtime 1.1)
		PackageVersion(RB 1.7623) ...)

Package(SmaCC-Development) >> untestedLatestPrerequisiteVersions
	-> #(
		PackageVersion(SmaCC-Runtime 1.1)
		PackageVersion(RB 2.0) ...)

Note that you could try to automatically load the newest/best(?) 
versions of
a Package based on this (computed) untestedLatestPrerequisiteVersions
(RB 2.0 instead of RB 1.7623):

Package(SmaCC-Development) >> loadWithUntestedLatestPrerequisites
	-> loads #(
		PackageVersion(SmaCC-Development 1.2)
		PackageVersion(SmaCC-Runtime 1.1)
		PackageVersion(RB 2.0))

This should store its currently loaded versions somewhere, if you have 
tested it
enough you just commit it and a new PackageVersion(SmaCC-Development 
1.3)
is automatically created and send to SM.

A PackageVersion can include code but does not have to do so,
as its prerequisiteVersions can.
Have I overlooked much? Is this far away from Gorans ideas?
I just saw that he also wrote a mail right now, also using some
illustrative examples... :-) Have to read this now...

Regards,

Markus