He means a plugin architecture - think dynamic linking, think plugins, think Photoshop, think the nineties (when plugins were all the rage ;))
So yes, a common interface, two or more distinct implementations. Both DLLs then reside in a well-known application „plugins“ directory and your app loads and links with them at runtime, on demand (see system call dlopen() and friends).
In fact, you basically already have a common interface: it‘s called „SimConnect“ 
So I‘d expect the implementations to be nearly identical (and they could hence be provided in a common, abstract base class which implements your plugin interface), give or take some flight simulator specific „boilerplate code“.
Essentially the two plugins would only be different in the SimConnect.dll they link with: for FS2020 you‘d link your plugin with the instance provided in the MSFS SDK, for Prepar3D you‘d link with the SimConnect.dll instance coming from the „Prepar SDK“ (or whatever simulator you want to support).
Because it is essentially the flight simulator specific SimConnect.dll that deals with the specifics (communication protocol, sim specific data structures etc.). Again, when developing against the SimConnect API you already have paid 90% of the entrance fee, so to speak
P.S. When I said „dlopen()“, don‘t worry: in C# I‘m sure you have a „higher level API“ to „dynamically load/instantiate/link with“ a class „on the class path“ (like in Java with the ClassLoader). And even when in the C/C++ world dthere is usually a framework (Qt in my case) involved which provides more convenient APIs, too (e.g. QPluginLoadern)