I think “classic” SD will be insufficient for many of the use cases in the long term; it would be awesome to have a skinny little data type just for storing references. This would do away with the need for these clumsy workarounds.
These references wouldn’t even need to be mutable, and their address (which matters only to determine storage location) could be computed from their content. They would have a fixed size (just a few hundred bytes) so their storage and lookup could be highly optimized.
It’s impossible to search SD for content (e.g. the references they may contain) so there’s no way to say “I want the tags belonging to this document” or “documents with this tag” unless somebody aggregated them (relying on which becomes a SPOF.)
If we had a very simple data type for [owner, category, label, reference, signature] that could be searched for a combination of owner, label, reference, it would be trivial to ask questions like “stuff tagged by this person” or “stuff tagged by this label” or “tags by this person for this document.” This could be the basis of many different applications, including simple tagging, search engines, RDF triplestores, WoT entries, etc
(the “category” field above is just a way to let one owner come up with independent sets of labels)
In my semantic search feature idea I also suggested a fuzzy search for the “label” in the above scheme: there are ways to compute (or manually assign) binary tags where values with a small Hamming distance (“XOR distance”) depict semantically similar content, which would allow for “search by example” (documents about related subjects, similar images, …)