From my standpoint, Orbiter looks like orbital physics engine with addons.
Look on all this more wide:
Today it runs with DX7 input and is x32.
Tomorrow it will become x64 core with DX9 graphics addon.
Later it will run on linux (I hope) natively.
Then it will run over network on many raspberies + PCs to simulate great simpit.
Question is: why to insert into orbiter core Windows gibrish API and prevent Orbiter to become crossplatform? Addons in Orbiter is great thing. You can add almost anything to orbiter without messing with with core. Simply changing one joystick support with another is short term solution. Why not to look in future and do things flexible from start, instead of patching what we already have. As I said before: I see that next gen Orbiter will loose build-in MFDs (tey will be enabled in modules tab) and exist as separate DLLs (or something else in linux). The same is already true for grapjics client, ang hopefully for input modules (keyboard, mouse, joystick, Wii, TrackX etc).
Right now I already patched Kamaz ORB::Connect+Web addon and can control vessel from web+javascript. That mean: If I want I can control vessel via TCP from arduino or whatever. I will pot modifications and binary on github soon.
Your solutions tight Orbiter to Windows only (or linux + wine) and USB cable when it is possible to do input stuff over Bluetooth, Wifi, Ethernet or even LoRA. Don't glue your solution into core, give a freecom of choice. Instead of gluing joystick into core, it is more practical to add some API functions and callbacks into core for more flexible addon implementation.