Just for clarity, lemme describe what I mean by server in my rail developer.
In scripts like the heartwood quester, when you want to rail, you just transfer control from the quester script to the called subs that will rail you from point A to point B. During that time, you cannot be doing anything in the quester since it's waiting for the called sub to return from the rail function. This is what I call blocking railing.
However, in a "server" arrangement, you have the rail engine actually running in its own separate tab. From there, instead of calling railing functions, you actually send "signals" to the server to start/stop/monitor. After that, you leave your script free to execute code until the server does its rail function to completion or failure. Just by monitoring the status of the server, the script utilizing the server motion can set the server up to rail again, or do another non-rail function in the script.
This gives your script the ability to scan for bad things, monitor health, look for items, update user interfaces, etc. This is what I call non-blocking railing.
If you take a look at my zoo donator, you can get an idea about the two different modes of operation.