A long as, as a developer, it doesnt force me to either queue when I dont want it queued, or go through a needless inefficiency getting to whateve the native level does then I say go for it.
Thats the point, expose the additional functionality without removing the existing. Both at the same time always. That way the developer gets to pick one, and it will always work.
If the plugin works in polls only, then the API will wrap it so that a developer can if they wish still use events. If the plugin only deals with events, then the API will wrap it so that poll works too. The underlying plugin does what it knows how to do, and with the aid of some helpers, exposes the other way too.
This way a console focused team using a future plugin can use poll, and still port their app to say linux, that at the kernel level, uses events, with no code changes. Also a PC/mac focused team can use events, and if in the future they wish to port to a console that at it's level uses polls only, then they will not need to make any chances either.
We can also mix things. Example, at the moment, the DX plugin gets the current data for say a joystick, but uses events for mice.
I want to make it clear, that this will mean that any user of jinput can use either method, with any plugin on any platform. The plugin knows how it handles events natively, and with the aid of helpers will expose both ways of doing things.
Full compatability *and* the user of JInput chooses how to use it.