This is great! I originally wanted fuzzy links but I couldn’t figure out how to adequately manipulate the default behavior of org 
I haven’t dug into the code or db for managing headline id links yet. Is it necessary to resolve the fuzzy file+headline links into proper id: links in order for it to save the link to the db? Leaving a file-only link fuzzy works just fine, and the fuzzy file+headline can otherwise navigate correctly – I just don’t see the headline version in the backlinks. I expected the behavior to be the creation of an ID property under the headline upon file save, and the backlinks buffer to populate the same as if I had a proper id: link. Since it can auto-complete headlines in fuzzy form and navigate correctly without id: resolution, it seems like it would be trivial to create an ID property and update the db without requiring resolution from fuzzy to id:. The implementation of a fuzzy-upon-edit behavior probably supersedes this issue – do you think the editing functionality will be simple to do?
Replacing roam: with the fuzzy links also breaks the demo implementation of Add Link-tags feature, so I need to come up with an alternative! Would something like link-tags be related to the implementation of link types? Except I don’t really want to define a new link type – simply annotate existing org-roam links. It wouldn’t be difficult to parse an implementation of link-tags out of the link-description section in any of fuzzy, file, or id types, but I would rather refactor with the most “correct” design 