yeah, the question does make sense.
The issue is, we didn't want MapStructure to be used that way
Seriously, we wanted to provide a framework to grow a library of reusable and style-able layers that live inside $FG_ROOT/Nasal/canvas/map
At the time, we were primarily addressing issues that arose due to heavy "copy/paste-coding", where people would gather useful bits from different places (aircraft) and then copy/paste, and adapt things as needed, with tons of code duplication and basically no reuse.
That problem arose primarily because Melchior stopped being involved in the project, so that Nasal no longer had an active maintainer around, which is why we are still seeing so much copy/paste coding going on in the Nasal department.
The MapStructure framework was designed to be a MVC framework to grow such a library of reusable components, that people could re-use and style/customize as needed, without having to duplicate the underlying logic at all.
Our hope was that aircraft developers would get involved in creating/customizing layers, and asking for feature requests, so that we could incrementally grow/improve this "charting library" for all sorts of different purposes.
Obviously, we would then get those new/improved layers committed to fgdata, so that they could be used in the future.
That was our hope at least.
Unfortunately, what really happened is that people wanted to be able to use MapStructure without requiring a certain fgfs version, so they still ended up using copy/paste to duplicate the needed/modified layers, so provide support for backward compatibility.
We really didn't foresee that development unfortunately. We were kinda hoping to "force" people into contributing their layers back into fgdata, so that their work could be easily reused by other aircraft/developers.
At the time, this was largely inspired by awesome avionics that were tightly integrated with the underlying cockpit/aircraft (think extra500, or the various Boeing/Airbus NDs), so that people could not easily reuse such code.
The MapStructure framework accomplished all the coding goals, but failed at the contribution level - because very few people felt comfortable writing custom/new layers at the time, and the few ones who did feel comfortable (and who succeeded), were so good at the Nasal internals stuff, that they simply circumvented our design, and explicitly loaded their copy/paste-layers into the MapStructure/canvas namespace manually, even though we deliberately failed to provide a corresponding API
I believe that artix and omega95 belong to the camp of people who have used the MapStructure framework and who deliberately worked around our design, so that none of their layers would need to be committed to fgdata - which meant that their aircraft would not be restricted by the FlightGear release schedule.
Other than that, the Extra500 folks might have adopted some ideas/techniques, but I believe they ignored the framework altogether, and simply looked at the code to borrow certain ideas.
It really isn't difficult to provide such an API, and it does exist already (again, artix came up with a pretty elegant mechanism). But the issue really is that this is not how the framework was designed to be used.
Personally, my recommendation would be to directly add your work to $FG_ROOT/Nasal/canvas/map (locally) and once you are satisfied, open a merge request and get this merged, and then you can simply raise the required fgfs version - obviously, I do realize that this may not be convenient from a compatiblity standpoint, but it's really the right thing to do from a software maintenance standpoint.
It would be trivial to provide a mechanism for "external" or aircraft-specific MapStructure resources, but I would suggest to also use a dedicated canvas/map sub-folder then, to encourage people to "eventually" commit their work back upstream.
Again, I do realize it's not ideal - but that's basically the current situation. It's all pre-dating rominet's addon system, which would provide for another elegant method to ship custom Nasal resources, possibly in conjunction with Richard's Emesary framework, but those two things were developed several years later.
For the time being, I would suggest to look at the MapStructure work done by artix and omega95.
It should be straightforward to generalize this, and append their loader logic to MapStructure.nas, and provide support for an aircraft specific default location for such layers, so that you can have your cake and eat it.
Right now, it's the equivalent of a hard-coded foreach loop with a pre-defined vector of filenames, certainly not ideal - but our intention was a different one, like I said, we really weren't aiming for a "plugin" system, but wanted people to contribute their layers to fgdata directly.
Stuart's FG1000 work (see the wiki/commit logs) also implement a number of custom/new layers, so he might have the latest experience dealing with this, and maybe he has a concrete suggestion on how to deal with this in the mid-term.