I'm pretty sure this has been discussed somewhat before but I think it's best to start a new thread to try to keep discussion fresh.
Something that's been putting me off from using this engine is the way that MUGEN handles reversed inputs. Generally in almost all fighting games that I've played, when p1 jumps over a standing p2 and lands - commands should immediately be reversed once p1 touches the ground. MUGEN handles this differently as commands are reversed - only when p1 has been "turned" - either internally by MUGEN's autoturn, by facep2 = 1 or manually through a sctrl. This problem is present is ALL characters - take any Ryu, have p1 jump and cross over p2, as you are about to land input a hadouken - it SHOULD only come out on (numpad) 214 + P, but since you haven't been "turned" it will instead come out only on 236 + P.
Here are (failed) solutions I've explored:
1. Put facep2 = 1 in state 52
This was my original solution but it fails if a move is inputted and buffered before the player lands. This is because p1 is not "Turned" upon crossing over p2 and inputting 236 while airborne and pressing Punch immediately upon landing will trigger the wrong direction hadouken.
2. Reversed commands based on p2dist x
I think I first saw this one, or something similar to this, in Bluestreak by JEsuszilla.
[Command]
name = "QCF_p"
command = ~D, DF, F, x
...
[Command
name = "QCB_p"
command = ~D, DB, B, x
...
And in the -1, having:
[State -1, L Hadouken]
...
triggerall = ( command = "QCF_p" && p2dist x >= 0 ) || ( command = "QCB_p" && p2dist x < 0 )
...
This essentially creates the opposite problems as the previous solution. Reversed commands work perfectly when buffered upon landing, however once p1 lands, there is a time when p1 is being "turned" by MUGEN's autoturn. During that short period when p1 is turning, p2dist x is also being switched as well and it is during this time where p1 can input 236 + punch and result in a hadouken.
3. Custom variable based command buffer via helper
This solution is currently in Vans' characters ( Xiangfei_LB and Shingo_LB ). Looking at the buffering system, it is quite complex but simplified it basically has every button and motion mapped to different variables that are initialized to a number when performed and counts down acting as its own buffer system as well:
; This example code is out of order but arranged top to bottom to make it easier to read
[ Helper's Statedef ]
;initialize variable number
[State 10371, LP Init]
type = VarSet
trigger1 = command = "x"
var(0) = 3
[State 10371, QCF Init]
type = VarSet
triggerall = command != "holddown"
trigger1 = p2dist X >= 0 && command = "qcf" && command != "holdback"
trigger2 = p2dist X < 0 && command = "qcb" && command != "holdfwd"
var(21) = 13
; Counts down when initialized
[State 10371, LP Dec]
type = VarAdd
triggerall = root, HitPauseTime = 0 ;^^ root, HitPausetime = 1
trigger1 = var(0)
var(0) = -1
[State 10371, QCF Dec]
type = VarAdd
triggerall = root, HitPauseTime = 0 ;^^ root, HitPausetime = 1
trigger1 = var(21)
var(21) = -1
And in the -1
[State -1, L Hadouken]
...
triggerall = ( helper, var(0) ) && ( helper, var(40) ) ;basically both qcf and lp have to be performed
...
This helper is also bound to p1's head position, meaning that it will perfectly detect which side p1 is on and which direction must be performed to get the move.
Quite frankly, this code actually DOES solve both of the problems as being in a helper, it will bypass being buffered by pauses (hitpause, superpause, pause) and the reverse commands work perfectly. But it comes with one fatal flaw... There is a one frame delay that occurs when the motion is inputted. Theoretically, though I may be wrong, I believe this is because MUGEN processes states in the order -3, -2, -1 then other states. Since the helper is definitely not in state -1, it takes one extra frame for the QCF and LP variables to be initialized and therefore the changestate in -1 will occur 1 frame after the variables and the condition is met. In addition, helpers do NOT get access to -2 and -3.
4. Put Vans' buffering system in -2
This is where it gets funny. Basically copying and pasting Vans' buffering system (and sacrificing a TON of variables) it pretty much eliminates that one frame of input delay and we appear to be fine and dandy. Until you discover MUGEN's internal flaw which is that commands are automatically buffered during hitpause, pause, and superpause. This becomes apparent mainly when another character does a super and "pauses" or "superpauses" - your commands are literally eaten up and buffered by that pause. Basically during the time that p2 pauses, MUGEN will continue to read input and once the pause finishes, the move will automatically come out the very first frame that the game is unpaused. This may also be problematic if any character uses a move with a really large hitpause and if you attempt to apply negative edge, it basically means that the button release will be detected indefinitely.
So this is basically the problem that has pretty much discouraged me from MUGEN until Elecbyte releases a fix for all of this. There is one solution that I have not explored and that is eliminating autoturn via AssertSpecial and manually putting all of the turns in. Unfortunately this is something that I don't have the time for exploring so if someone does manage to do this and is successful, their code will be promptly stolen 
Anyways, if you made it this far - thanks for reading.
