I think for the most part you would find transitioning to Scrivener relatively painless. Here is how I would approach your project:
- Install Pandoc if you haven’t already, and relaunch Scrivener. This will add a few built-in compile file types to the list, notably ePub. And for KDP hard copy, it also puts together a very nice quality .docx file that you can control the formatting for up front as a template (Pandoc level, not Scrivener).
- Since you have a series of .md files, the easiest solution will be to select them all in Finder and drop them into the Draft folder as a bulk import. This will not do any processing, which is by and large what you want.
A secondary approach would take more manual labour, but if you intend to do serious editing and further writing and work, it may be worth the effort. That will be to use the File ▸ Import ▸ Import and Split… menu command, selecting each .md file individually, and using the option to split by headers. If your sections are rather long, and include several semantic headings within them (Scrivener recognises hashmark style headings), then the result will be to import each chapter as an outline hierarchy based on that structure. Leave all other options default (you specifically do not want to convert Markdown, that’s for rich text users looking to abandon the workflow).
You will note that it strips the headings when doing so—that’s fine, and in keeping with how Scrivener is designed to be used, where when you compile the heading structure is built from your outline structure. You may see the advantage here immediately—moving a section around in the outline automatically changes its hashmark level if need be. You no longer have to worry about keeping your hashes in order.
- Now for the footnotes. Both MultiMarkdown and Pandoc support native footnote syntax, which will be much better to make use of than raw HTML. Scrivener supports the generation of this syntax with its native footnote features. There is no automatic way for it to convert your manually designed HTML into its native footnote features, so that is something you’ll need to do by hand (at least, I don’t think Pandoc can do anything magic here, may be worth some research). Within Scrivener, regular expressions and macros will help a lot here.
I believe you probably could just use what you have already, nothing in this workflow would get in the way of it. Again it’s probably a case of how agile you want this project to be going forward. Converting to the native footnote workflow will mean effortless management of them going forward, not to mention Scrivener’s many features for working with them (imagine for example a list of all your notes in the sidebar, where you can peruse and click to jump straight to the point in the main text where it is referenced).
- Once you have the basics imported, you should run a quick test. The stock ePub output via Pandoc is quite vanilla on purpose, eventually you will want to create a custom compile Format with CSS and other tweaks to make it look good. But you will get a ToC (both visible front matter and internal), full ebook metadata support, nicely formatted endnotes, a semantic outline and the ability to easily cross-ref between headings, and a lot of other good things. KDP should be able to import this ePub, but as that isn’t something I’ve tested, that will be one of the things you want to test early on to make sure this is even viable.
For DOCX, since Pandoc turns heading structure into a word processing outline, slapping a ToC at the top of the file is usually a matter of using a menu command, much like inserting an index (and look into our built-in Pandoc Word compile format, which includes handy styles for indexing).
To answer your specific questions:
For the most part, Scrivener’s formatting capabilities (read Styles in a Markdown-based workflow) are gravy rather than a necessity. You can dump raw .md into the program and get a great output. Some even prefer that way of working entirely, as it makes it possible to use Scrivener as a data source rather than direct editing environment (perhaps you prefer writing in Sublime Text or similar for its syntax generation and highlighting capabilities).
Styles are extremely useful if you need to go beyond Markdown syntax, or what Scrivener is capable of converting to Markdown—the user manual that nontroppo referred you to demonstrates this technique. I use simple styled text in the editor to mark special ranges (like menu commands), and then the compile format takes those and inserts output specific syntax (LaTeX in that case, but it could be anything).
I already mentioned one example above: indexing. Pandoc doesn’t have native syntax for that as far as I’m aware, but our built-in format will inject raw DOCX XML to build the metadata you need to insert an index easily after compiling, so long as you use the styles that format has provided, in your project.
That should be already be answered given the above. You could abandon Markdown and go full RTF native if you wanted to, but if so, I would not recommend manually doing so or even using Scrivener to convert it. Use Pandoc or MMD for that, nothing is going to be a better job of creating a .docx/.odt file for Scrivener than either of those tools. But again at that point we’re talking about a total conversion of how you work, and you’re still probably going to have to handle your raw HTML footnotes somehow.
Not the best approach—it handles .docx and .odt better, and the former better than the latter.
Somewhat irrelevant in ebooks. Unless you wish to painstakingly format them yourself in a way that won’t work well with most book readers. With ebooks “endnotes” are the best approach, and readers will appreciate that (often getting software popups instead of hyperlinks you have to jump to-and-from for). Since most readers won’t be manually flipping through pages by hand anyway, it doesn’t matter too much if your notes are long.
But with the hard copy that may be something worth looking into. I personally do not have a lot of experience with Pandoc+DOCX outside of basic tests and occasional usage for internal documentation. I don’t think there is native support for multi-stream notation in the syntax, but that might be something that could be achieved with Lua scripting and creating your own output filter—there may even be a solution on the ’net.
Another approach here is to have Scrivener convert your Markdown to an RTF workflow during compile. So nothing changes on your end of things, but there is a checkbox in the compiler’s General Options tab that will offer to perform this conversion on the fly. With that you can select Scrivener’s native DOCX output, and it is capable of multi-stream notation, provided you use both of its internal streams: inline footnotes and inspector footnotes. The latter is better for long form notes and the former is better for short stuff like citations—but either can become endnotes or footnotes.
So that’s something worth testing early on as well against your source material, as it would change how you convert from HTML notes. And yes, you can functionally use a mix of inline/inspector notation with Markdown. Scrivener will generate the internal reference tags using a different prefix for each, which although neither Pandoc or MMD will do anything with, does give you a hook for post-processing. You could treat [cf23] as the an endnote and [fn18] as a footnote, for example—that’s where the Lua scripting might come in handy as a custom Pandoc output filter.