Hi Jake
We haven't ever updated a Fireworks' metadata after running it, but some options would be:
(i) create a secondary MongoDB collection that stores metadata about Fireworks but is separate from the FireWorks core collections
(ii) update the fw spec within a Firework to include something like "tags" like you said
(iii) update the fw name after completion to include your metadata like you said
(note also that if we are talking about workflow-level metadata, there is also a "metadata" key that belongs to Workflow objects).
The first option is of course completely safe since it's separate from FireWorks itself.
The second option is fine if you know what you are doing. The built in commands for FireWorks try to encourage safe behavior for the most part, e.g., to prevent you from changing information about how the run was executed after it was executed. But, if you know some MongoDB, you could easily just change the spec using straight Mongo commands. As long as you weren't reckless, you wouldn't ruin anything.
The third option seems non-optimal to me. Since the name of the Firework is a string, you won't be able to structure your metadata very well when embedding it here. Also, I tend to think of the name as something of an id that one wouldn't expect to change. That said, FireWorks itself doesn't put any importance in the name and you can change it afterwards if you like (e.g., via MongoDB). But I'd note that some frameworks built on top of FireWorks (e.g., "atomate") require certain names and if you are using atomate in particular, you shouldn't change the name afterwards.
Basically, my suggestion is to just use MongoDB to add whatever information you want afterwards. But I'd also be interested to hear the proposed functionality to see if there is something more general to add to FWS.
Best,
Anubhav