Good find! From what I can see, with the way the the mdx library is building up the component (reference), we'll have to treat scope.props differently, as injecting props into the scope as we are now understandably conflicts with the local props reference generated by mdx itself.

Effectively what we are doing here is wrapping the result of running mdx in a function to create the scope:

fn (props, props2) {
  return function MDXContent(props) {
    // local props would shadow props from scope
  }
}

I'll do some thinking on a sustainable way to accomplish this. Feel free to contribute if you've got something in mind!

@BRKalow I've just run into this issue. I have to admit I was quite perplexed when only the props key didn't work. I'm forced to use this codepath with my setup. I'll noodle on this and get back to you with some ideas.

Okay I've done a bit of poking around and I came up with a solution that works, though you may not like it. To bypass the shadowing issue, I think we can simply use the props that are passed to MDXContent. I think this intuitively makes sense since we are trying to pass props to the component, so we may as well use the front door rather than the window. For example, if we change the hydration from src/index.tsx:

@@ -70,10 +70,11 @@ export function MDXRemote({
     // if we're ready to render, we can assemble the component tree and let React do its thing
     // first we set up the scope which has to include the mdx custom
     // create element function as well as any components we're using
+    const {props = {}, ...remainingScope} = scope
     const fullScope = Object.assign(
       { opts: { ...mdx, ...runtime } },
       { frontmatter },
-      scope
+      remainingScope
     )
     const keys = Object.keys(fullScope)
     const values = Object.values(fullScope)
@@ -88,7 +89,8 @@ export function MDXRemote({
       keys.concat(`${compiledSource}`)
     )

-    return hydrateFn.apply(hydrateFn, values).default
+    const Component = hydrateFn.apply(hydrateFn, values).default
+    return () => <Component {...props} />
   }, [scope, compiledSource])

   if (!isReadyToRender) {

This will extract any props from scope and inject them into the MDX component via the traditional route. I tested this as a hack via my browser debugger but I'll look into forking this and testing it as a full-fledged change. I think in reality it may make more sense to add a props: P field to MDXRemoteProps<P> and add type parameter <P = {}> to MDXRemote.

@rfrowe Sorry for the delay. If you're still interested, feel free to open a PR with this and we can take a further look!

@BRKalow I've opened a PR for this, please take a look.

No need to make any change in the package, the issue comes from the way of implementation.

You can use like props.foo expression in the mdx file by using a recma plugin depicted below.

See mdx-js/mdx#2437

Therecma plugin is recma-mdx-change-props for the issue.