Sorry to have missed your comment.

Basically:

    ---
    import foo, bar, baz
    ---
    # Markdown
    
     * Goes
     * <https://here.com>

eg: https://docs.github.com/en/contributing/writing-for-github-d... ... https://jekyllrb.com/docs/front-matter/ ... and google search for "rst yaml frontmatter"

If you take an `*.mdx` file and run it through a typical markdown renderer, you'd get something like... well... lemme give the counter-example: if you had the "dashes" delimiting your "frontmatter" from the document, you'd get something like:

    <hr>import foo, bar, baz<hr>\n<h1>Markdown</h1><ul><li>...etc...

...the critical part being to relatively unambiguously demarcate "junk" from "content" in the markdown ecosystem. In the far future when this project is but a forgotten memory of time, people can still just straight up render the markdown and "obviously" delete the stuff between the <hr's> up at the top.

The contrarian is that there's ambiguity as to when your `*.mdx` "import junk" stops and when the actual content starts. Do you stop parsing [for imports] after the first blank line? Do you stop parsing when you get a syntax error? Do you only parse lines that begin with [import ...]? What about [from ... import ...]?

More google searches: `http header demarcation rfc`, and eg: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...

...strong recommendation: demarcate "headers" from content (a-la HTTP). Your format effectively becomes `---\n $PROG_LANG_GOES_HERE ---\n $CONTENT_HERE`, and you slide 1000% into "pure HTTP":

    GET /foo.mdx

    Content-Type: application/mdx
    Date: 2020-10-10 01:02:34

    ---
    import SomeComponent
    ---
    <SomeComponent>My Header</SomeComponent>

     * Some
     * Content