Folks, there is a substantial difference between what you call an “SDK” and what I believe most people would say an “SDK” is (the same goes somewhat for the well-known term “API”).
Of course you can call your own work whatever you’d like, but I’d suggest you stick to the “generally used terms and definitions/meanings” if you intent to implement a new API.
So let me quickly write down the “generally accecpted definitions” of SDK and API:
- SDK simply stands for “software development kit”: I couldn’t spell it out better than Wikipedia does, quote: " A software development kit (SDK) is a collection of software development tools in one installable package."
So it is not a single DLL (a DLL is simply an implementation detail, if you wish), but really the entire set of what the vendor provides to 3rd parties to create add-ons etc.
Ever wondered why Microsoft is calling the installation folder of the SDK “MSFS SDK”? Exactly! 
Because that’s the folder where the entire software development tools are contained: that includes also applications (tools) for creating scenery (if MS provided such tools, never have checked all what’s in the SKD myself ;)), possibly also compilers, shaders, paint kits… that’s what people usually refer to as “SDK” - as “software development kit”.
- An API is basically the “set of methods, functions, types and (global) variables” that allows an application to interact with another application (or “system”). In fact, an API specification can be totally separated from an actual implementation - think Open API: “API first” development etc. Or as Wikipedia puts it: " In computing, an application programming interface (API) is an interface that defines interactions between multiple software applications or mixed hardware-software intermediaries.[1] It defines the kinds of calls or requests that can be made, how to make them, the data formats that should be used, the conventions to follow, etc"
So when we talk about the “SimConnect API” we are of course not talking about the actual implementation (which is contained essentially in the client SimConnect.dll - or the static variant thereof, doesn’t matter). We are of course talking about this:
See? It even has “API” in its name So this constitutes the functions and types with which the client (“your app”) interacts with the server (here: FS 2020).
The fact that a “managed API” (C#) exists - and many “wrappers” for other languages - doesn’t impact the generality of what I just said about “API”, we are still essentially talking about functions like SimConnect_Open and friends. Or in other words: the C# SimConnect API is an “adaption” of the “API specified for the C language” (the SimConnect.h essentially), to make it (better) suitable for C# programming conventions (and to make it callable in the first place, of course).
Now when you say “My aim is to bypass the SDK completely, allowing us to demystify the Protocol (communication process) used by the SDK/API, and thereby permit us to communicate directly with the API” that is actually wrong (in terms of how people generally use the term “API”): yes, you are communicating with some API (*), but that is the internal, undocumented (as you have already figured out ;)) server-side API which is not public (and hence not meant to be used directly).
(*) You could say "everything is an API then! Even a simple function that returns “Hello, World!”. And in fact you would be correct But when we talk about an SDK and it’s API we are mainly interested in the “public and documented API that developers are supposed to use”.
The way a 3rd party app is supposed to communicate with FS 2020 is via the official, public and documented API, as defined here:
Again, we are simply talking “naming / definition differences” here and I don’t mind if you keep / use your own definitions and terms. But it did create some confusion for me