For example 1, the difference can actually help determine if a device has a POV input or not at startup, which you then can treat it as you want to in code (if your goal is an initial auto configuration). For example, after you execute 'CompleteRawJoystickDetection()', run through the available POV commands to determine if any are returning a '-1' indicating they are live. You can then set up a default mapping to one or more to listen to the POV('s), otherwise, you can turn it off by default if it's '0' at startup. If it did return a '-1' at startup even if it didn't exist, then you wouldn't know if it were available or not and you'd need to leave if off by default and have the player enable it manually.
One thing to be aware of though is that DirectInput will often
not return any signals from a connected device until a non centered signal is received, so it's possible that with some devices, any axis, POV, or slider input will sit at '0' anyway until an input is moved. As a result, some device may default to no POV anyway even if they have one, but for the ones that are picked up on startup, you could use the '-1'/'0' difference as a way to automatically map controls.
For example 2, device enumeration and usage has always seemed weird on Linux in any control system I've tried to use. You may also notice that device names can return very strange strings. There can be double input signals and mismatched values relative to Windows, so you'll want to account for those in code. They are hopefully pretty consistent from system to system at least, so you should be able to account for them once and find the same behaviors on other Linux systems. I don't know for sure though as I haven't been able to test across different distros and devices much yet. Ultimately though, if you have an input that returns more than one signal, you can simply ignore one in favor of the other. And with a control mapping system, this can also be left up to the player to let them chose which input return they want to map.
But also on that note, part of the challenge with the signals you get with Linux is that the POV inputs depend on those split signals. That is, you must listen to both inputs to determine what angle the POV is actually at. I use this code to determine POV angles listening to 'GetRawJoystickSlider(DevNum,1)' and 'GetRawJoystickPOV(DevNum,0)', with the 'jhatpov[]' array being used to store an integer that selects which angle the POV is at starting with '1' for 'up':
rem Linux mode POV/HAT input
LinuxJoyY=GetRawJoystickSlider(ii,1)
LinuxHat1=GetRawJoystickPOV(ii,0)
jhatpov[ii,0]=0 ` idle
if LinuxJoyY=0 and LinuxHat1=-32767 then jhatpov[ii,0]=1 ` up
if LinuxJoyY=32767 and LinuxHat1=-32767 then jhatpov[ii,0]=2 ` up + right
if LinuxJoyY=32767 and LinuxHat1=0 then jhatpov[ii,0]=3 ` right
if LinuxJoyY=32767 and LinuxHat1=32767 then jhatpov[ii,0]=4 ` right + down
if LinuxJoyY=0 and LinuxHat1=32767 then jhatpov[ii,0]=5 ` down
if LinuxJoyY=-32767 and LinuxHat1=32767 then jhatpov[ii,0]=6 ` left + down
if LinuxJoyY=-32767 and LinuxHat1=0 then jhatpov[ii,0]=7 ` left
if LinuxJoyY=-32767 and LinuxHat1=-32767 then jhatpov[ii,0]=8 ` up + left
This is currently the only way I know of to retrieve POV data from a device on Linux. Kind of tricky, but hopefully consistent and reliable.