As for using docked rails and storage I would think the best way to configure the direction of pull being like this. (Assuming entity A is docked to B.)
Entity A has a rail docker as the master with a slaved storage block, on entity B there is a master storage with a slave connection to the rail. The master storage on B would end up pulling from the slaved storage on A, much like how storage transfer works on the same entity.
That would then allow the reverse to happen, and a master storage on A with the rail docker as the slave would be able to pull from any storage slaved to the rail on B.
After that the control of items following to/from these storage blocks would work like it does now and can be controlled very well with logic.
As for my bit about salvage beams.
You could have a little salvage beam for pulling items from an exposed storage, which could work both ways to load items from or to a ship or a cargo box. This could be used to ignore the slaving/docking aspects of transfer which would be better for trading between ships of different factions.
Entity A has a rail docker as the master with a slaved storage block, on entity B there is a master storage with a slave connection to the rail. The master storage on B would end up pulling from the slaved storage on A, much like how storage transfer works on the same entity.
That would then allow the reverse to happen, and a master storage on A with the rail docker as the slave would be able to pull from any storage slaved to the rail on B.
After that the control of items following to/from these storage blocks would work like it does now and can be controlled very well with logic.
As for my bit about salvage beams.
You could have a little salvage beam for pulling items from an exposed storage, which could work both ways to load items from or to a ship or a cargo box. This could be used to ignore the slaving/docking aspects of transfer which would be better for trading between ships of different factions.