obscure <constraints> question

OK, put on your I-am-an-ARK-nerd hats... I seek your
guidance in order to avoid a potential bad design/language
decision...

Let us say that, in searching for a field thing (along a
prototype path), you encounter

  <constraint><dependency name="foo" version-spec="eq 1.2.3" /></constraint>

and then subsequently

  <constraint><dependency name="foo" /></constraint>

.  At the moment, the ARK engine seeks to satisfy these two
constraints entirely independently.

So, assuming we're talking packages, imagine we actually
have foo packages versions 1.2.3, 2.3.4, and 3.4.5 all
installed.

The first constraint would be satisfied by package foo
version 1.2.3; the second constraint would (and might) be
satisfied by any of the three (because there is no
'version-spec' attribute on the second constraint).

Proposal: in satisfying a constraint, we give preference to
constraint-satisfiers *already encountered* for this field.
In the example above, the second constraint would be
*guaranteed* to be satisfied by package foo version 1.2.3,
because we've already used that to satisfy a constraint.

Why: it will make it easier for a site-team to specify
versions in its own xml files, and for "policy" teams
(e.g. Sidai) to express constraints, knowing that they tie
up with what the individual site wants.

Opinions?

Will