...
Requires server answering purl dns name and forwarding/responding based on information from new resolver. Would require change of existing workflows to stop assigning new purls.
Support migration of data from staging repository (e.g. Datastar) to long-term storage/preservation repository
The base requirement here is almost the most obvious use case for a PID system: Imagine some data is added to the Datastar repository and is at some later stage migrated to another repository for long-term preservation, it would be good if the id originally assigned were a PID that remained persitent during the migration.
Two possible issues: 1) not all things in the staging repository will later be migrated, some will be deleted. What is the cost of issuing PIDs for items that then get deleted (how many?). 2) migration will likely by a single objects or small groups rather than a whole repository. This must be automated as part of the repository transfer process.
Support for flexibility in access/cache system
It seems likely that access to content in some repository systems will be provided via a caching/access layer on top of the base repository. This is fine in that we can imagine the PID resolver knowing that all access should be directed through that layer. However, for large or frequently requested items there may be a need/desire to serve these from other sources (say cloud storage or even some edge network) to save bandwidth changes and/or improve service. Ideally, use of such facilities would be automatically and dynamically determined (access layer could monitor logs to identify candidates for such treatment).
Redirect to another access/cache service could be done either at the access layer (extra redirect, no implication for PID system) or by some dynamic rewriting of PID resolver data (save redirect, issues of maintenance, coherency etc.). Seems that at least initially one would opt. for the former though the latter is interesting.