I agree for sure, and it's definitely a feature worth working on!
This is about the point where I'm at the limits of my knowledge of the implementation of this feature and the IDF, but here's a simple example that highlights why this isn't "trivial".
Let's say there's a function "do_esp32_thing" in the IDF. You'd like to use it from both the main micropython firmware, but also from your loadable shared object. (Perhaps the function is something like "set_pin_mode"). The simple answer is that both the main firmware and the shared library include a copy of this piece of code (i.e. at link time, they both statically link in the relevant bits from the IDF object files). But now you have two copies of it on your ESP32. Or equivalently, what if you had two shared libraries that both use this IDF function?
It would be nice instead if the build system was clever enough to realise that this bit of code that you want to use in your shared library already exists in the micropython firmware. But where is it in the firmware? Can you rely on the address being consistent across builds? What if it's been inlined, etc.
These are all "solved problems", of course. Most of the time you don't have to think about this on Unix/Windows because the loader is much more sophisticated and you can afford to spend lots of bytes on symbol tables and stuff. And not to mention _lots_ of bytes on implementing a sophisticated loader. But this is MicroPython. (And TBH, even on Unix/Windows/etc, you do still end up thinking about this stuff pretty often)
This may seem like a contrived example, maybe having two copies of a function isn't too serious. But maybe a better example -- what if you have some ESP thing initialized in the micropython firmware, and the state is stored in some variable from IDF code somewhere. Now you use a totally different function in your shared library, but that function also uses that shared state. The compiler needs to know where that variable lives so it can generate correct code to access the variable in the right memory location. (Or the loader needs to be aware that it needs to fix it up at load time).
The way the native shared library feature (as demo'ed by Damien in those videos) works right now is that a small set of helper functions at known locations provide access to core micropython functionality. Also because the interface it's providing is based on sort of "Python-level" operations, it's simpler -- being a dynamic language, Python essentially provides a high-level loader like functionality anyway. (i.e. operations like "get the value of attribute 'foo' from this object"). Which is great if you're accessing Python functionality (i.e. most of MicroPython), but not so great for generic C APIs.
This isn't an issue for the QR code example from the videos because it (the QR library) is an entirely self-contained piece of code that has no other dependencies or shared state. Ok that's not actually true...it depends on (IIRC) strlen() so there's some handling for that.
