Lex,

> I don't understand.  The issue is what a Package object will 
> look like. It will refer to other packages by reference in its
> dependency information.  What should this reference look like?
> A human-readable name, or a UUID? 

Both. That's my point. This is not an 'either or' situation as you need to
look at both sides. As you mentioned, it is very convenient from the
maintenance point of view to have UUIDs (no need to rely on names etc). But
from the user's point of view it's a mess ;-) So you want to be able to use
both. If you encapsulate both, name and UUID into some PackageReference
object, then you are trivially able to do this. You are even able to change
the name of some reference 'under the hood' if the system finds out that the
name of some package has changed (for example, a package reference might
actually look up the name of the package in some global registry but you -
as the user - are still able to think about 'this guy having a name'). The
only thing that's important here is that both are - by default - associated
with a package and that you treat them 'as one' rather than as 'either or'.

> What would it mean to have a reference with both a UUID and a 
> name?  How do you perform the dereference when you are ready to
> download the real package object?

When you 'ultimately' dereference a package you do it by UUID. However,
there are only very few places where this is required. For everything
'inbetween' you should use 'real objects' (PackageReferences) which allow
you to think in whatever way is more convenient to you.

Cheers,
  - Andreas