This is a visual artefact only, to allow the client to get back in sync with the server, without having to speedup the rail movement.
As in general a slight speed variance would be easier to notice, we allow the rail to move directly toward the server position.
The server remains in charge of keeping the path checked, so they cannot travel otherwise impossible paths if they would have followed the rails properly, but it gets a few milliseconds back to be back in sync in a short time.

Tried it again, and it worked properly.

Okay, from the sole building type and construction the turret should work.

Can't seem to reproduce, I changed a basic rail into other rail types and orientations, but its connection with the storage chest was still there.
Do you have a blueprint of a ship where this is happening? Upload it here (drag and drop the file into the comment section) and I can take a look at it.

Does this still happen from time to time, or at all again?

Raising priority due to a changed behaviour.

Perhaps I'm misunderstanding what you're trying to say, but the Personal rank is only useful within your faction. For anyone outside your faction, they can't control your entity anyway no matter what the faction rank is set to.
I don't see how it could work if you're not in a faction?

Can you please upload the launcher.log from your launcher directory, right after trying the new launcher, and also the logstarmade.0.log after trying the old launcher.

Was the extraction process done with windows unzip or linux unzip?
I assume as zip has in general no proper sparse file support its not really something we can fix, except adding a restore backup feature, that can then write sparse files then.

Not actually a bug, but if they have constant inflow of blocks, its protected from being moved, as the race conditions could lead to blocks being destroyed or created.
While the first case would not be too much of a problem, the second case would be an exploit.

Can you still reproduce this? Or does it still happen?
I believe we fixed that issue or a related one, quite some time ago, but it may not cover this one directly.

That may have been fixed now but we need the author to reproduce and provide the logs to be sure.

Possibly fixed with fixing beams recently. needs retesting.

Related to other issue with similar NullPointer (probably not needed though). Shutdown error is possibly fixed already

Unfortunately not enough with just this snipped. need at least full log. Essentially this is a state where a player character was hidden but is still in the physics which is illegal. I suspect either sector change or F1+F8 to be involved

T1004 has been fixed. Not sure if this one is happening. A station turning into a red platform would only be possible if there is no data to load. Need logs if this should happen still

Impossible to solve without log

I just checked and noticed that there's also Ctrl + Shift being used as a shortcut.
It's something we can't fix or improve upon since every Windows User will have their own setting.
Here's how to change it, or to turn it off:

Needs more information

Great thanks! I watched your youtube video and it may be a cross-sector thing.
Your target was in sector 63 64 66, but you were shooting it from 63 64 67 at some point

Do you have that station on a server?
I'd like to examine it and find the cause.

Can you still reproduce this?
Played around with this a bit, and could not see any problems.

Wow, can you add a screenshot or give a coordinate of the problematic rail-speed controller?

Asked @Benevolent27 for a sector export.

Waiting for replies/details in Z34.

Looks like the blueprint has a different state of it then.
Server and location? going to visit it there then.