That's why one of my options is a custom hash algorithm table; Multihash has explicit support for using your own hash functions. AFAIK part of the implementation of custom hash function table entry in Multihash is a protocol to encode metadata alongside the hash, e.g. by appending the salt to the hash, perhaps separated by some special character (e.g. base64 encoded hash + ":" + base64 encoded salt). This is not part of the table, so maybe that would make it inconvenient to use. I haven't read enough of the code to know.
I do think it would be much nicer to have this in the Multihash library itself. Easy hash function migration is a great feature to have when you have to store user passwords.
I also find standardized text-based formats for storing multiple types of hashes in one field interesting, but I'm not sure if it's worth the effort to implement myself vs. extending Multihash. I like that Multihash encapsulates the parsing logic and that it has libraries in many languages, so I can easily interact with the DB entries from e.g. scripts or new codebases.
I think the cool thing about Multihash is the very broad platform support, the small scope, the convenient API to interact with a DB + hash function table, and the default function table; I'd only be missing out on the default function table if I were to use a custom function table.
