It’s difficult to know where to start. Clearly the SDK Documentation needs to address specifics on how to utilize the many parameters available. Without explanations, creating an accurate flight model and accurate engines is next to impossible. First tier developers have to go outside the SDK and custom code to get results they want. That is not how it should work!
Asking the community of developers to describe where the SDK is lacking is not appropriate. The developer’s role is to create aircraft with the tools created by and described by Asobo. Asobo should certainly have an aerodynamics expert on staff as well as someone with flight dynamics experience developing aircraft using Asobos tools. These individuals should be side by side, working together to determine the problems Asobo is asking the community to discover and creating solutions. They should have a coder and an SDK writer at their disposal. Let’s call them the Flight Model Development Team (FMDT). They need to be making determinations such as, "this is inaccurate, this is redundant, this is unnecessary, This needs good explanation, etc., etc. The list could go on.
A Flight Model Development Team could go a long way toward solving the frustration of Aircraft developers.
You beat me to it 
Whilst I agree with you about the developer’s role (and from both our discussions and chats with others behind the scenes the complete lack of communication about the flight model is hurting a lot of people from many dev houses), I will paste below my post from the original thread that was ‘sidetracked’, in order that it is here and can hopefully be a starting point to getting this awful situation addressed:
You asked for specifics as to where the SDK was lacking, because you had heard that mentioned but never been given such specifics. I touched on it in my earlier post, but with the DA62 project open in front of me here are some pointers as to why people may be suggesting that the SDK is lacking in detail. Or actually, just lacking . . .
Obj ea1 surface:
Position ok
Direction ok
Span, sweep, incidence, dihedral, twist ok
Can dihedral take a negative? The tailplane couldn’t in 2020, but there are plenty of aircraft out there with such a thing so it would be nice to know anhedral is accounted for.
Stall alpha - okay
Stall alpha ff - Fuel flow? Free flight? We need to know what your abbreviations mean.
Element weight - ok
Element spacing - means absolutely nothing to me. I am defining one object. How does a single object have spacing?
Element width - ok
Element number - how is a coordinate relevant to this?
Size - ok
Relative position of the surface - ok, but could do with confirrmation that this is relative to the model centre position.
Surface Cx - ok
Surface Cx normal - well surely that is just Surface Cx, already defined?
Surface Cx efficiency - no idea at all.
Surface Cx nscalar - no idea at all
Surface Cx npower - no idea at all
It may interest you to know that a google of the three Surface Cx directly above gives nothing relevant to aerodynamics but the last one does lead me to an energy supplier for my electricity . . .
Compliance - no idea.
Damping - does not make sense to have a single damping effect without specifying in which directional plane it applies that effect.
Hard depth - absolutely no idea.
Front scalar, back scalar, front scalar ratio, back scalar ratio all mean absolutely nothing without explanation. The first two are already a scalar on something, and then a ratio on a scalar???
Dim Scale I mentioned previously - needs clarity or at least a note about how it functions.
Linked behaviour index - absolutely no idea.
Surface angle (deg) - no issue at all.
Modifier - modifier of what?
Modifier angle scalar - so that’s a scalar to the angle of the thing I don’t know?
Modifier position scalar - as above, but to the position of the thing I don’t know?
Modifier surface relative position scalar - do I really need to . . . ?
Group - presumably binary, but there appears to be no description anywhere of what each index is?
That is just ONE file out of several, which we are expected to use to build objects within the flight model. I would say that at leat 3/4 of it is not documented, not standard aerodynamic theory and not straightforward to understand.
This is where you get the comments along the lines of the quote in my previous post about flight dynamics currently being a “hostile environment”, combined with the fact that many flight dynamics questions in the later stages of 2020 (the last 18-24 months) were seemingly met with a wall of silence.
There is a strong feeling amongst developers that the SDK is inadequate. There is an even stronger feeling amongst those of us that work solely in flight dynamics that the SDK is pretty much non-existent where it matters. It’s very pretty, with descriptions and pictures of boxes around points. It is very comprehensive in the theory behind how it works. But it gives us NOTHING to tell us how to put Asobo’s ideas into practice.
To go a stage further and talk about the implimentation of defining the shape - how on earth are we at a stage where the simple shape of an aircraft requires the complex nature of all the confusion above? Why can we not just load the wireframe model in an editor and drag the points to surround the shape precisely? Then have a modifier file for aerodynamic behaviours?
I think “hostile environment” is an understatement.
There are plenty of posts with questions about the FS2020 flight model SDK that have never been answered.
Be that as it may, Eric asked for this thread.