Hiya.
Wanting to export my doc to multimarkdown for use in Obsidian while preserving the internal wiki-style links. I can export the files to multimarkdown easily enough, but it seems like all the links disappear to other internal docs.
Any suggestions?
Yes, if I understand you correctly, and you are using internal Scrivener links, then any kind of export, sync or compile to plain text is going to drop them since that is a kind of rich text formatting. Of course, with Compile there is a checkbox that will convert such internal links to MultiMarkdown format; check the general options tab (gear icon) for that setting. That might be all you need, so long as you intend to work with the entire compiled .md file as a single note, but it’s worth mentioning that a MultiMarkdown/Pandoc heading reference isn’t something Obsidian recognises. I.e. you reference a heading with [Heading Title] in CommonMark, but in Obsidian it would need to be [Heading Title](#heading-title) (or something like that). But, if the idea isn’t so much to have these be functional links in Obsidian, but functional once you use MMD to make an ODT file or whatever, then that is fine!
What I do myself is always mark links with Markdown around them, if I want that link to be something used outside of Scrivener. This gives me total control that the aforementioned checkbox does not. I can have links that are purely for my own internal benefit, and links that will become cross-references of some sort when I compile. The Scrivener user manual project contains copious examples of that. In conjunction with the wiki link formatting in Scrivener, I basically type three opening brackets, then a bit of the title and use the completion shortcut (in Edit â–¸ Completions) to fill it in, then three closing brackets. Scrivener takes the two inner brackets and strips them, leaving just the hyperlink formatting, and the third set of brackets remains around the link, which is what Markdown will use.
One thing to bear in mind is the fundamentally different approach to linking between the two programs. Scrivener, being an outliner-based writing program, treats outline items as headings more naturally. So a Markdown cross-reference heading to [Name of Binder Item] will become a clickable link in HTML, or a word processor, etc., to that heading in the singular final document. This is the kind of linking the user manual benefits from. Obsidian on the other hand is a multi-file note program where one must put the heading structure into the documents themselves. You might still link to a heading, but it’s going to need to address the note name as well.
Ultimately, I don’t know if there is a really seamless way to merge how these two programs work, given their differences. But again if the idea is more to have a document that will be functional to MMD, that may not be fully “functional” (as clickable links) in Obsidian, then yeah, you could more easily bridge the gap.
Also refer to this recent discussion, where the intent is more to have actual Obsidian “link cloud” compatible links in a way that works with Scrivener’s folder sync feature. Might not be what you’re doing, but I figured it worth dropping a link.
That’s a shame that the internal links can’t work out of the box when exporting to multi-file .mmd
I wrote a python script in the past to turn the single compile-based .md file that Scrivener exports into a dokuwiki compatible bunch of .md files that preserves links. I was hoping to not have to revisit that code and make it work for Obsidian.
Thanks for the thorough response 
Part of the problem goes back to some of what I way saying about, about how internal links tend to point to headers within a single document, so their usage intent doesn’t really overlap with [some text](binder%20title.md). I.e. I suppose we could make a checkbox that does that, it probably wouldn’t even be that difficult, but ordinarily you wouldn’t be using links for that purpose, and rather something more like, “See Subsection 12.8.3 (pg. 172)” in the final output.
But speaking of multi-file output scripts, you may have come across it before, I made a simple demonstration of using compiler post-processing, with a simple Ruby script, to generate a folder of .md files. Or really, it could be other types too, as demonstrated earlier in that thread, where the script runs MMD on each split-off file to generate a folder of .tex files.
Not too far away from what you made, it sounds like, though maybe the idea of coupling an automatically executed script with a compile format that inserts file markers is new. It makes it the sort of thing you can do one day, and then switch to another Format and get a singular .tex file the next day.
I guess I’m confused on how the internal links work.
I get that when you compile to one big dock, it does the links in the [some text](binder%20title.md). For Export style markdown exports, though, can’t the already existing internal links just be reformatted to the standard .md style of [[mdfilename|Link Display Title]].
Just for absolute clarification, I am using the internal wiki-link style links where you type [[ then the doc name and it links to the internal doc within scrivener.
Maybe I’m being overly simplistic and missing something, which is obviously very possible, haha.
Hmm, I think I may be confused as well now. 
I get that when you compile to one big dock, it does the links in the [some text](binder%20title.md).
It’s the other way around; that was an example of what the Export feature would hypothetically have to do. What compile does is generate [Binder Title], because that is what MultiMarkdown and Pandoc will be using to look for ### Binder Title, somewhere else in the same .md file.[1]
…can’t the already existing internal links just be reformatted to the standard .md style of
[[mdfilename|Link Display Title]].
That isn’t a Markdown though, that is how Wikipedia formats links. Granted some Markdown tools use that (Obsidian among them), for some good reason I’m sure, but it’s best thought of as a non-standard custom syntax, like their block linking is. It isn’t going to work in any standard Markdown conversion tool (not least of which because no file name is given, yet it is definitely an external file link).
But mainly I’m not sure if converting internal cross-references to anything at all in the Export feature makes sense, since the reasons you would use to internally reference headings are not the same for why you would externally link to an entirely different file on the disk. The only argument I can see of it is that there is probably nothing better to do with it anyway, but reasons like that feel a bit thin when adding new features and complexity.
Just for absolute clarification, I am using the internal wiki-link style links where you type [[ then the doc name and it links to the internal doc within scrivener.
The difference with Scrivener is that uses those as a typing trigger to generate RTF formatted hyperlinks, rather than as markup. The brackets are removed once the hyperlink is created—and at that point it doesn’t matter how you made the link. If you click into the Quick Search toolbar field and drag and drop a search result into the editor, it’s the same exact thing at that point.
So maybe that makes more sense, if that wasn’t known? We’re taking the same kind of hyperlink you might find in LibreOffice, and looking at the target of that link. If what it points to is in the binder, included in the compile job, and if the title of what it points to is the same as the link text, then we print [Binder Title], which is valid Markdown for an internal cross-reference. If the link text differs, then we print [here is the text of the link][Binder Title], which is also valid Markdown for this. In all other cases the link is removed.
Well, it might still be using the older [Binder Title][] form, which has been largely moved away from by MMD and Pandoc, as it is unnecessarily cluttered. ↩︎
Okay, that clears it all up for me. Clearly, one of my fundamental mistakes was thinking that the wiki style internal linking was a markdown styling.
Thanks for taking the time to give that explanation!