Problem: people want to know things about packages other than version and load script.
Solution store/retrieve name-value pairs
Alternative name?: [package meta]
No required names; let conventions arise
How do package variants share a single metadata?
When does metadata need to be available? Only after loading a package? Or earlier?
If earlier, [package about] calls need to go in index scripts, and automatic indexers should be able to place them there.
Does this complement or compete with TIP 59? If compete, who wins?
This would mesh well with the metadata provided by TIP 55 (see Cantcl) which could be available before loading packages. Since the format is name/value pairs it fits into the above scheme.
I'd suggest [package info ...] though and perhaps a more sophisticated query interface. Eg. [package info -subject web] might tell me the names of any packages with a subject field of web that are currently installed. [package info -repository $url -identifier ncgi] might give me info (a pair list?) about a package in a remote repository.
DGP Greater sophistication is fine, but I see that as additional functionality to be built on top of a very simple [package about] command. I imagine that first [package about] provides the primitives, then conventions arise for good conventional name/value pairs that should be used (inspired by TIPs 55 and 59 in part, I'm sure). Then when conventions are established, more sophisticated procedures that process [package about] information according the the evolved conventions. This separates policy from capability. I think that's a good thing.
Is there a need for setting metadata values?
DGP If we never set them, how can we query them? So.... Yes.