One comment on this - it's worth clarifying/emphasizing that there are two kinds of IDs being discussed in Jim's document.
There are LR envelope IDs, and there are resource_locator IDs. LR envelope IDs (aka doc_ID) is just a way to identify the envelope so we can refer to it again later. This lets us do replication, and it will in this new model let us do updates and deletes.
The resource_locator is used to store generally the URL of the resource being referenced. It is currently a string and we are proposing to make it "polymorphic" so it can be a string or an array of strings. If it is an array of strings, each string can be a distinct URL (or URN or any other identifier that is relevant). Each string in the array is considered "equivalent" to the other strings (probably not as rigorous as "owl:sameas" which is truly identical but more just semantically the same - one might be a flash video and one might be an youtube link but they hold the same content). There will clearly be variation in how this is implemented by different publishers, but that seems ok if everyone is working towards that goal of telling others about resources which are the same as others.
When creating a URN for doc_ID, as Jim proposes, this could imply selecting one of the URLs/strings in the resource_locator for part of the URN, over the other resource_locator URLs. This shouldn't be considered a "canonical" selection of that URL as the definitive one - just an arbitrary decision for representing uniqueness inside LR, which is the only purpose of doc_ID.
Anyway that's my two cents. Anyone who wants to join the call this afternoon (in about 10 minutes) should definitely feel welcome to do so.
Best,
Steve