Input System Proposal

When playing video games, there are some games whose input systems frustrate me. There are some common issues - like inputs being dropped because the game's graphical rendering freezes - and there are some more game- or genre-specific issues, like when a Fighting Game has input motions which I view as too strict, buggy (reading inputs that aren't there),  or generally poor in their support of Keyboard inputs.

My proposed system would be my exploration in trying to solve these errors.

I will begin by targeting the Windows platform. I've used this system before, and there's a decent example of the absolute bare-minimum in the Engine we've been working on already.

I will start by first giving support to Keyboard.

From here on out, the rest of what I will write is suggestions that I will use as direction for my System.

I would like to explore providing a simple interface for re-mapping inputs.
I would like to explore extending support of this interface to at least one Controller - Game Pad or Fight Stick -  if this is not already handled by drivers. If it is, then it would still be interesting to look at detecting what type of controller is plugged in.
I would like to explore finding a way to minimize or eradicate "dropped" inputs.
I would like to explore an optimization of my Input System - instead of the Input System listening to all possible inputs, it only queries inputs which the user's Game subscribes to.
I would like to explore giving the Interface user controls: how often querying occurs, how long the buffer of saved states should last, etc.
I would like to explore having a pre-made set of detectable motion inputs (e.g. Quarter-Circle-Forward) that the user of the Interface can listen for and simply expect my system to handle the detection of.
I would like to explore some type of Debug output similar to games like GBVS:Rising or Street Fighter 6, which displays the current button-press state and how many frames/queries the state lasts for.
I would like to explore having events, such as Button Pressed and Button Released (and inferring a Button Released Event even if a Button Released frame is somehow dropped).

I've listed enough things here that I would expect to have covered goals, stretch goals, and then some. However, if for some reason I manage to burn through all of this (I won't), then I guess I could explore extending support to a platform like Android?

Challenges I expect to run into:
If I dive into seeing what controllers are plugged in, I imagine I'll run into a spaghettified mass of drivers.

I may simply not find a solution to dropped inputs. I shouldn't expect that I'd be the person to solve this problem!

What I personally view as "strict" inputs might be very different from someone else. Inherently, I think such a system needs to have tunable variables (unless, like a Fighting Game, I just want to tell people to get good).

Per-machine complications.