The best tool is no tool at all (some suggestions, please critique them)
Initially put this down in the discussion on future-proof tools, but that reply was silently deleted. 
A lot of us are concerned about the "interoperability" of our digital ZKs. Will they still be usable in 30 years? The simple response is that nothing's better than plaintext files, which we all know already, but I believe there's more to the picture than that. I'm currently staring at my own zk which is juuuust at the point where re-factoring everything is still possible in a sane amount of time before there's "no going back".
Only rely on the tools that you can expect any decent operating system to have.
Imagine if someone found your zettelkasten and had no special software to explore it, just the filesystem and OS-level tools. How difficult would that be for them?
We can assume two things:
- They will be able to search by file name
- They can find a way to search the text itself (every operating system can do this. Windows has file indexing, everyone else gets grep, everyone SHOULD get our lord and savior ripgrep, there will be more.)
That's about it. So let's think about this. Here's what I'm planning on sticking to, I'm hoping people criticize this.
Technical Considerations
- We should only use ASCII characters in our notes if we can help it. They're both the most consistently encoded text characters on the planet and might be more efficiently searched. So no plugins that automatically replace keyboard input with more typographic UTF-8 equivalents like proper curly quotation marks or emdashes. (I am aware that if you take your notes in any language besides English this is dubious, unfortunately we Americans had to do our thing.)
- Same goes for file names. Additionally, we must avoid characters that filesystems hate including spaces.
- Our Markdown must be as interoperable as possible. My money is on Commonmark, but additionally, HTML should be avoided for compatibility with Pandoc (we'll get to why).
File and Folder Structure Considerations
- Folder structures necessitate file paths in links, ugly, avoid. Possibly useful to have a folder for attachments like images to separate concerns.
- UIDs are good, sorry. I hate them too. The file name should ONLY be the UID as this makes re-"naming" notes independent of linking to them, and makes OS-level search tools just search only for references to the note rather than any text which contains the note title.
- Header H1 as note title. This means titles are still searchable via the methods above.
- We NEED "index" notes, "hub" notes or MoCs or whatever. These are your entry points into the vault exclusively, using UIDs as file names necessitates this if you want to parse what's going on in these notes in the future. These notes SHOULD get descriptive file names which make it clear that they're index notes.
Note composition considerations
- Markdown is meant to be highly human-readable even without a Markdown "reader" and we should consider that in how we format our notes. This is why I am against folder structures (ugly links). This is why I am against using HTML tags in notes, even without the Pandoc consideration. This is also why I believe that reference-style links are superior. Reading
[this is a link][1]and seeing the link itself at the bottom of the page is vastly more readable than inline links.[^1] - Once again, treat H1 headers as note titles and only use one H1 header per note. This is helpful for searching for titles in a pinch, as searching this text (
# note title) should, like UIDs, only return the note title and not other matching text in your notes. - Metadata should be used sparingly and it should be in the form of YAML, and that YAML should always be in the form of lists. Personally, I'd only use YAML for "tags" and the tags should only describe very broad concerns that go beyond something which should get a specific index / MoC. Even with no editor your YAML metadata may (theoretically) be searched this way (
- your tag here)
Screw readers, we've got HTML
- This is why I brought up Pandoc compatibility. You can, in fact, convert each of your files into HTML web pages, meaning that you can read them (with formatting and links) in any web browser. You don't need to host them or anything, just keep the folder structure the same. ...I have yet to go about doing this, but I know that it's possible with Pandoc's --standalone flag and some scripting to convert every file at once. I should try it sooner rather than later.
[1]: I have major beef with Obsidian right now specifically because of it's refusal to just stick to proper Markdown standards. "Internal" reference-style links outright don't work in Obsidian currently. Footnotes, on the other hand, which are just a common extension to the Common Markdown standard, do. Can anyone sound off on whether their editor supports this supposedly standard Markdown feature?
Howdy, Stranger!
Comments
User-created consistent rules are important, and interoperability is important, so it's good that you're paying attention to both.
Your rules are not exactly what I use, but are similar to what some other people use. A couple of recent similar discussions that come to mind are "How to maintain knowledge over decades" (last month) and "The GRID system for frictionless Zettelkasten organisation" (last year), not to mention the relevant blog posts by the proprietors of this website.
My note system is in macOS, and due to my use of very long filenames and some use of characters in filenames that are illegal in other operating systems, my note system is not currently portable to other operating systems (however, the content of the notes is highly interoperable). If I needed to move to a non-Mac operating system, I would have to use a script to convert the filenames and links to a compatible form.
Your title is "The best tool is no tool at all", but in my case I would say, "The best tool is having good enough scripting skills to fix the mistakes that made your note system less interoperable than it should be"!