I was thinking of something like dabaubR where each successive leg should not be longer than the previous.
If I understand this correctly that means a Rook that relocates the friendly piece at the end of its extrapolated move to any of the squares it passed over. Requiring a certain order of the intermediate 'transition squares' is difficult for back-and-forth movement, but comes automatic when you always move in the same direction. E.g. the Valkyrie in Odin's Rune Chess is basically a simplified version of what you use here, which can ony relocate a piece on its destination. Rather than first picking off the piece, and then moving back to the point where you want to unload it, (which would require length restrictions to not overshoot the origin), I described it as first moving to the unload square, and then continuing to the target ([Q-udQ] or afudQ). That automatically guarantees the unload is between origin and destination.
So in the case you describe you could at least first move to the unload square. Unfortunately there is no such freedom for the destination; this always has to come last. So you would get an m slide to the unload square, fud slide to the piece that should be relocated, and then an m slide back to the destination. The 3rd leg should be shorter than the 2nd, which you can enforce by making the last leg an i leg, and split the 2nd leg into two: [Q-uQ-dQ-ibQ] or afuafdaibQ. Another way to look at that is traveling origin - unload - destination in the same direction (to enforce the order), followed by a friendly rifle capture in that same direction.
(I think that this is what Bob had in mind too, but he wrote the u in the wrong place.)
If I understand this correctly that means a Rook that relocates the friendly piece at the end of its extrapolated move to any of the squares it passed over. Requiring a certain order of the intermediate 'transition squares' is difficult for back-and-forth movement, but comes automatic when you always move in the same direction. E.g. the Valkyrie in Odin's Rune Chess is basically a simplified version of what you use here, which can ony relocate a piece on its destination. Rather than first picking off the piece, and then moving back to the point where you want to unload it, (which would require length restrictions to not overshoot the origin), I described it as first moving to the unload square, and then continuing to the target ([Q-udQ] or afudQ). That automatically guarantees the unload is between origin and destination.
So in the case you describe you could at least first move to the unload square. Unfortunately there is no such freedom for the destination; this always has to come last. So you would get an m slide to the unload square, fud slide to the piece that should be relocated, and then an m slide back to the destination. The 3rd leg should be shorter than the 2nd, which you can enforce by making the last leg an i leg, and split the 2nd leg into two: [Q-uQ-dQ-ibQ] or afuafdaibQ. Another way to look at that is traveling origin - unload - destination in the same direction (to enforce the order), followed by a friendly rifle capture in that same direction.
(I think that this is what Bob had in mind too, but he wrote the u in the wrong place.)