I aggree Logseq doesn’t emphasize Markdown compatibility, far from it. And Markdown is a bad choice for anything database-worthy. If they really wanted, it’s possible to make clean markdown. But Markdown is not created for metadata and Logseq doesn’t want to use clever workarounds to make clean Markdown even with metadata although they clearly use extra data in the Markdown files and still call it Markdown-compatible, which is misleading.
I have managed to avoid exporting anything from Logseq and strived to use the very Markdown files Logseq is using as data structure atm by some clever using of multi-line link titles and don’t consider it any more hack-ish than adding extra, unsupported markdown syntax. If Logseq would support Multi-Line Titles in Markdown Links (as it’s CommonMark standard Markdown) it would even be easier, prettier.
I’m getting this way clean text and still retain the custom properties I create to have structure. I also don’t have any difficulty to write over and over again the syntax that makes this possible because I use Logseq’s text expander (custom commands) with every Note Type i usually enter in the journal so i don’t even have to think about it -as most my notes are atomic and each note has a type that is defined as custom commands.
For TODOs i use unicode characters in inline Markdown Links that look like [🔳]([[TODO]] " #de ") (I actually use many more “#de*” tags to narrow down queries to my needs and use the [:editor/input "" {:last-pattern "<" :backward-pos 37} ] custom command syntax to position the caret right adter “de” (“to” - in my native language) to write at the Note Capture time the exact type - #defacut #deexplorat #desunat etc). This way my notes render ok in both Logseq and markdown (instead of [ ] and [X] ) and I can query for the exact tag. The only thing I loose is the Ctrl+Enter functionality for the TODO, which is replaced by a custom command like <info or <book which then gets me a block template where i achieve much more functionality than the single TODO introduced by Ctrl+Enter.
There are many things one can achieve customizing Logseq if he really cares about the locally-first approach.
I don’t say Markdown is the best format for anything, less a database and even for clear text it’s still in a hard drive that is 0s and 1s and an open source database is about the same from that pov. I would have liked a JSON-based db to be frank, which is still text-based and there are examples of such dbs out there performing very good.
Nevertheless all this discussion is kinda useless as long as the db-version is coming and the bi-directionality will not be a feature of that one.