You're thinking of midcast and aftercast. GS processes those after receiving a 0x28 packet which has nothing to do with 0x1A (outgoing) which is the request for action that precast is bound to. Could be wrong, but I'm certain you can get locked into a precast set. It's happened and most GS users that do dynamis complain about it.
I'm the author of Ashitacast, I know the packets. Come on.
Precast, Action, and Midcast are all queued in the same logic cycle. This is how you can precast instacast gear and still have the cast execute in midcast set. The server reads the whole packet without breaking thread. This means that since it's reading in precast gear, then your action, then your midcast gear, you will never have anything else occur while in precast gear, provided your midcast swap is appropriately set up.
It's a convenient excuse for dying, sure, but it's not true. You might briefly see precast if the server > client communication is too large for one UDP and sends the precast updates without the midcast updates, but as far as the server's concerned you're already in midcast before anything else happens.
Ironically, the same can't be said for JA, where any enmity set has to remain on until the action is registered. In that case, you can be hit in the wrong set.