Are offset travel and network node direction limiting mutually exclusive?

Greetings,
while working on my stock picking simulation I ran into an interesting limitation.
In my simulation a vehicle (taskexecuter) drives in the middle of the aisle between two racks and a stock picker (operator) picks flowitems from the racks and puts them on the pallet on the vehicle.
I used pickoffset proxy task (x-coordinate only) in order to position the vehicle in front of the cell from which picking is performed.
Because of the vehicle dimensions (2.5 m long) I have created the path network so that if the vehicle has to go back to the cell behind it, it has to go out of the aisle, U-turn, and drive back in.
Except it does not seem to work after I call the pickoffset task.
After the pickoffset proxy task has been executed the vehicle drives to the exit node without any regard to the path network, restricted direction of travel, it makes a U-turn in the middle of the aisle (you can mentally picture the "huh???" emanating from the customer at that point), and drives through the racks. Normal behavior restores after the vehicle reaches the exit network node, but it is too late by then.
Herein lies my question: is there any way to work around this problem so that the vehicle stops halfway between two network nodes, but still remains associated the travel network and obeys direction of travel and no overtaking rules?

Is there another way of solving the vehicle positioning problem? I have not tried "traveltoloc" but I suspect it will cause a similar issue.
I am modeling a large warehouse and placing a network node in front of every bay is probably not the way to go.

Can you share your model on the forum or post a small example? If not - maybe post a diagram to help convey the scenario and the way your model is set up?

Hi Jason,
Here is a small model that showcases the problem. I imagine that once pickoffset task is executed the vehicle is off the grid and all bets are off, but I cannot figure out a way to fix that short of placing a network node in front of every bay (bad idea).

To solve the problem in that model you could try adding subtasks to do the following :
1) record the location of the current pickup so the next traveler can see how far I'm going without inspecting the task sequence.
2) before each pickoffset, see if you can travel to the next pickup point, and if not, travel as far as you can and then enter utilize task (state_waiting or blocked).
3) if you travel forward look at the next traveler and if it is waiting call freeoperators.

You'll probably need the same subtask call after the utilize in the subtask so it'll be kind of recursive - that shouldn't matter as long as the calls don't get too deep.

You can find the current travellers of the Entry node (<NN> below) using this:
ownerobject(tonode(get(up(tonode(get(rank(getvarno de(<NN>,"travellers"),<#n>)))))))

where you replace <#n> with the rank of the link under the travellers variable.