HitBox-style controller "last input priority" direction input behavior differs between games running natively and through Proton

Please excuse the confusing title. I'm seeing a repeatable, predictable situation where games run through Proton do not register inputs properly on controllers with a certain type of axes behavior.

"HitBox" style controllers that use buttons for directions have "simultaneous opposite cardinal direction cleaners", which ensure that impossible direction combinations (e.g. left and right simultaneously) are not sent to the game. These cleaners also define the behavior that should happen instead --- one such option is last input priority, which sends the most recent button press, overriding the previous opposite button. The behavior of this method is different between native Linux games and games run through Proton, and the nature of the different, incorrect behavior is consistent across Proton games I have tested.

When I run Skullgirls (245170)'s native Linux version and enter training mode, if I...

1. Hold left, I walk left;
2. Simultaneously hold right, I walk right;
3. Let go of right, I walk left.

This is also visible in e.g. the KDE Plasma Game Controller tester.

1. Axis 7 = -32767
2. Axis 7 = 32767
3. Axis 7 = -32767

However, if I launch Skullgirls through Proton (forcing "Steam Play", version Proton-6.19-GE-2), I get this behavior:

1. Hold left, I walk left;
2. Simultaneously hold right, I walk right;
3. Let go of right, I stand still, but can see in the Plasma Game Controller tester that Axis 7 = -32767.

Additionally,

1. Hold right, I walk right;
2. Simultaneously hold left, I stand still (and again can see Axis 7 = -32767),
3. Let go of left, I walk right.

Similar behavior on the up/down:

1. Hold up, I jump continuously;
2. Simultaneously hold down, I crouch;
3. Let go of down, I stand still (Axis 8 = -32767).

and

1. Hold down, I crouch;
2. Simultaneously hold up, I stand still (Axis 8 = -32767);
3. Let go of up, I crouch.

I see this particular faulty behavior across Proton games I've tested: Skullgirls, BlazBlue Central Fiction (586140), Guilty Gear Xrd -REVELATOR- (520440), and DoDonPachi Resurrection (464450), and have confirmed expected behavior in native Linux Skullgirls, Corpse Party (251270), and Danganronpa: Trigger Happy Havoc (413410). I also tried running my system wine control and it looked like I was getting the expected behavior in the Windows-y tester, but I don't know how useful that is.

In all situations, if I use a traditional joystick lever instead of buttons, everything works as expected, native or Proton. If I had to make a guess, maybe somewhere in Proton/wine the stack is looking for the axis to return to neutral (-32767 > 0 > 32767) and falls back to some different behavior when it doesn't? I don't think an axis can be "depressed" and "pressed" in the sense that it'd be looking for me to depress the left button and press it again before it registered left again, but I don't know.

Frankly, I recognize this request is kind of deep in the weeds, but it definitely makes a lot of Proton games only kinda playable on my setup, as specialized as it is. I'd of course love it if someone skilled with Proton/wine knew exactly what to fix, but I can write C code and kinda understand what to do, if anyone has breadcrumbs for what I should just tinker with, I'd appreciate any help I can get.

Thanks.

Start by reproducing the directional-input sequences in the Plasma Game Controller tester and the listed native and Proton games, comparing them with wine control. Trace how Proton/Wine handles HitBox-style opposite-axis transitions; done means matching native behavior for left/right and up/down when either opposing button is released.