Why do you want this? We will not promise that our internal C APIs are stable. The only way to have something native that is maintained is by merging it into this repo.

@tannewt I followed the original MicroPython discussion on this over months. The idea is just to make it lower overhead to add special-purpose modules, segregated in another directory. Anyone using this would need to maintain a fork. I don't think we'd recommend using this except for private stuff. It doesn't flow with shared-bindings, shared-modules, etc. but it does make it easier to add a simple module.

@dmazzella Anything general-purpose (e.g., an FFT module, or something like that), we would like to see submitted to us as a PR, even if it's turned off by default.

One advantage of having this in our fork is that it will make merging from upstream easier next time, since it's already included in MPy. At the next merge, we'd either have to merge or discard it (manually).

@dmazzella Please describe what you are using this for.

Feel free to comment on why you need this and I'll reopen. I'll close for now.

@tannewt sorry if I answer with so much delay.
I use this feature from upstream to isolate the repository of my features from the upstream one. I find the possibility of not having to apply patches, forks or creating branchs to manage my native modules very useful.