I think it would open up some powerful possibilities if packages in a "Project.toml" were only identified by their UUID. So in e.g.

JSON = "682c06a0-de6a-54ab-a142-c8b1cf79cde6"

"JSON" would just become an arbitrary alias, resp. the local name used for "682c06a0-de6a-54ab-a142-c8b1cf79cde6" within the package/project with that "Project.toml".

This would enable us to rename packages at will without breaking code referring to those packages under their old names.

For example, let's assume (I'm not involved in either package, and this is pure hypothetical), the maintainers of "JSON" and "JSON3" agreed that "JSON3" (I guess it's faster?) should become the new default JSON-package. So we they could rename "JSON" to "JSONOld" and rename "JSON3" to "JSON", but keep the UUIDs. Any other package that still refers to "JSONOld" as

JSON = "682c06a0-de6a-54ab-a142-c8b1cf79cde6"

would just continue to work, while packages that want to use the newer JSON package (formerly "JSON3" could use

JSON = "0f8b85d8-7281-11e9-16c2-39a750bddbf1"

This would also enable us to tidy up the package namespace a bit (as long as the package maintainers agree) - I guess we have quite a few packages that, for historical reasons, have names that are either to general or don't fit the package very well anymore (e.g. after it has evolved and broadened or narrowed it's scope).

This would also resolve name-clashes between packages from different registries (e.g. between general and a private registry).

In principle, fully UUID-based package resolution would also allow for having multiple packages registered with the same name within the same registry - IMHO this should definitely be avoided though, at least in general, as it would create lot's of confusion. A name should be "freed" before another package can claim it.

CC @StefanKarpinski (we discussed this in Baltimore, but I forgot to write it up as an issue.)

I'm not able to judge if this would require major changes of if it could be implemented fairly easily.