To fix the problem, one must first understand the problem. There are THREE different reason delay occurs.

1. Connection issue. Self explanatory enough. This is USUALLY not an issue within a server, but can be problematic in ANY Xserver event.

2. Flash rendering. The server assumes that flash is rendered perfectly at the speed set. Unfortunately, this isn't always the case. On more modern systems, rendering can be kept up at 1x, but falls behind on 2x as the animations aren't sped up as much. And on older systems, it is possible that the client can't even keep up rendering at 1x speed, thus falling behind.

And finally, #3, chase and animated mystery. This, in a way, is an offshoot of #2. The problem here is that the server does NOT wait extra time for those to resolve. Instead, it simply allot the same amount of time as it would with an attack/mystery that does NOT cause chase or have animation. But as the client need to render these animations, it falls behind. It is even possible for longer standard attack animations, such as that of Minato, to also contribute to this, as I suspect the server waits for the exact same amount of time for every standard attack.

As a result of any of the above, client state can fall behind server state, either because client didn't go as fast as it should or because server wait time is not properly allocated for chase/mystery. And once there is a difference in state, we will see the delay problem. Specifically, when we issue a command, the command is queued according to the server state, which is "the future" compared to client state. While it might still be in the middle of the round on the client side, the actual server state, and thus when the command will result, is either later in the round or even after the round, thus causing the command to be queued toward next round.

There are, IMO, two methods toward solving this.

1. Logic path: Give extra mystery cast options of "reactive casting"(only when target cast something) and "queued cast" where it will be cast when able(if currently unable) and "cast at last opportunity"(where it will be cast before the turn end for prompt and right before its standard for non-prompt). Generally speaking, those three will be all that player wants, so even if we are not seeing the correct state, we can still issue command that we wanted all along.

2. Configuration path: configure the server to wait properly wait for the client. To be clear, problem #1&2 are mostly the player's problem, the server should NOT wait for those(except Xserver issues, that's more of a stability issue, and animation should be sped up more on 2x). But for #3, the server need to allot sufficient time for every mystery, chase and, should it be a problem, extra long standard attacks to resolve. Once the server actually wait the correct amount of time, client side will no longer fall behind due to having to display all those.

Comparing the two proposed solution, #2 seems simpler while #1 is more complex and in, in a way, only a workaround. So we should do #2, right? The thing is, #1 will work now and always, with ONE change. Whereas #2 will require constant maintenance. Because to know how long the server SHOULD wait for, one must take into account just how long the mystery/chase/standard attack actually takes. This means that you will essentially need a time chart for every single action in the game that needs to be kept up to date with every ninja introduction and skill change. This might have scaling issues. Also, I'm not entirely sure how easy it might be to have it properly calculate the time of a chase chain, which in theory is simple addition but depend on the coding, might be complicated.
Or, of course, every action that can be taken will wait for the maximal amount of time an action of that category needs to take. (Say all mystery waits like Garras, all standard waits like Minatos, thankfully I think chase all have the same amount of time per chase). But this could make the game slower than before, which might negatively impact GNW, which does time out every now and again.