I believe You didn’t make it on purpose to stamp out community works. I hear You about current and proposed solutions.
I remain unconvinced they will match the speed and ease of access of the old ways, but maybe You guys can surprise me and I’ll eat my words.
As concerns the fate of 3rd party market, time will tell, we’ll see.
Best wishes 
Is the intention to integrate this into the in-sim toolset or as an external conversion tool like XnConvert? Are the specs used for your custom container published anywhere? I could not see them in the documentation?
Vote #1 on the importer. This is incredibly vital for livery makers to be able to make new liveries whether they be texture based or the preferred method of decaling with the new sim. Also, kind’ve vital if the package tool is going to enforce a requirement for an uncompiled model reference in its build process whether needed or not.
I’m going to add my voice to the seeming dissatisfaction about the route that developing is taking specifically within the Flight_Model area, having finally managed to get the game to open, stay open and let me build the SDK sample! The first point that I would like to make, and this is really fundamental to a lot of Flightsim dev work but especially so in regards to the topic of flight models, is that many (probably most) of the people working in this field are hobbyists. People that have real-world jobs that can take up a lot of their time and leave limited hours for this hobby. People to whom the idea of spending days, weeks, months even learning processes and areas of computing that they have never needed to use before is likely enough to turn them away from this hobby. I started working on flight models when I gave up real world flying because I was dissatisfied with the realism of sims at the time. Starting in FS9, I learnt from the likes of Pam Brooker and John Cagle and contributed to a hobby that required little more than an understanding of flight, an ability to translate that into text or air files and the ability to test that in game. Please bear that in mind when reading this and many other posts - your 3rd party devs are often not armed with the same level of resources or time that you have, but as has been proved time and time again (and referenced by others in this thread) they are key to the ongoing success of the MSFS franchise and my personal opinion is that every effort should be made to make things work for them, as much as for Asobo. @EPellissier your continued engagement here is very much a part of that and is appreciated, but there needs to be far more practical help in the area of the flight model - that is ‘my’ tagged subject here, so I will remain focused on that.
Taking points already made - IF the quick reload is replaced by a much faster Build Package button, then that may be okay. As a flight model developer, when I’m dialling in a figure (e.g. speed for rpm under a given set of circumstances), I could be making tens or even hundreds of tiny adjustments reloading and re-checking after each one. Quick reload was sub- one minute. That has to be what you are aiming for, and it has to be a one button press. Talk of ‘creating another package’ is no good for me - I do not code, I just work on how aircraft fly, as mentioned above 
Why would I want to do anything other than directly modify the flight models which are my responsibility to create for the companies which ask me to and who supply me with a package specifically to do this? I think the quote
perfectly describes the flight model dev environment as it currently stands.
It would be incredibly helpful to have a straightforward description of, and possibly even an example of, how the completely new bits that are not addressed at all in the SDK work (if they are in there, I have failed to find them and apologise, but again if they are there they should be clear and blindingly obvious):
First point is a massive change and a potential trip-up for any dev, so I have to ask why it was done this way - in the DA62 SDK build, the engine positions appear to be defined laterally, vertically then longitudinally (or it could be Lat, Long, Vert, it doesn’t say). This is a break from all previous location standards in both 2020, FSX and prior which have always defined points Long Lat Vert. Looking in the Aircraft Editor, there is no definition of which is which and it also means that we now have both of those position definitions within the one game, lack of standardisation.
The modular build in the flight model has some points that are probably straightforward (Dim Scale - dimensional scale, defining the actual shape?)
Surface Cx, fair enough but three numbers behind it? What do they refer to and how do tangent, normal and efficiency affect behaviours?
element_number = 6, 3, 20 total number of sub surface elements composing our surface template - what are 6, 3 and 20? How is that relevant to a flight model if they are sub surface (other than weight, which I believe is addressed elsewhere)?
Nothing I can find in the SDK addresses these, and again in the Aircraft Editor there is no information, just a series of boxes to fill in.
Things that may be seemingly simple to the people that built them, but when unleashed on Devs with no explanation take a lot of head-scratching and trying to reverse-engineer what’s been built into default aircraft (yes, another reference to Devs doing that as a standard, we’ve been doing it since pretty much FS5.1, because we have never really had such an SDK as you have provided us with but it’s still severely lacking where it matters!)
The Aircraft Editor - this is something which had many issues in 2020, and is something which I steered clear of for everything other than the ‘Gizmo’. Are we now to trust that this works with no issues? It adds nothing to the ‘clarity’ of the SDK - perhaps you could look at Aircraft Airfile Manager to see a truly useful tool for flight model development: displaying your lines of numbers (tables) as a graph, so that oddities are spotted quickly, decent notes that explain what each parameter does with clarity, accuracy and brevity, a simple layout that is (in my opinion) far more user-friendly than the aircraft editor.
I know what I have written probably sounds overly negative, but I have always spoken my opinion bluntly and truthfully (the day job requires it 
) and I find that trying to ‘be nice’ whilst getting a point across invariably masks the points being made. I will just add that I am in awe of what Asobo have created. I wish it was a logical, open and straightforward environment to work in.
I have a couple of commitments, but unless there is drastic improvement in clarity and simplicity, I believe I will be heading the same way. When the confusion and frustration outweigh the enjoyment, it is simply no longer worthwhile as a hobby. Given the issues but especially the UI of 2024, I will likely not even use it but instead use a combination of P3D and 2020 for ‘enjoyment’ when that time comes.
Every devs best option is to just make modules for 2020 then port to 2024 and scrounge whatever money possible from FS24 until this console-catered dumpster of a casual game meets its fate.
Very well put Phoenix! I sure hope Asobo listens. Without guidance the frustration will drive me away from 2024 as well. It’s unfortunate. I was so looking forward to all the flight model improvements that were being advertised. However, without guidance and functional tools to use them, I’ll be out this “game” as well.
I tried this flow, but either I am to dumb or there is a bug!
More of my findings when I find the time and I am in the mood to write a detailed error report.
Think I will stop with writing mods for MSFS until I can work at a pace I am used to. Until then, back to sim-racing modding.