The problem
Now, no matter how fast carts travel, they are immediately stopped by lockdown tracks, etc.
This appears unrealistic and could cause cart glitches in a train possibly.
Morevoer, if we have such a speed control, we can add speed-limiting signal aspects like "approach", "approach diverging", "approach medium", etc. to our signal system.

The solution

• An advanced train speed control system that integrates with locomotive modes to control the train's speed.
• Addition of "restricted speed" concept: under that speed, tracks can stop a cart/train immediately; otherwise, the track would apply a "brake" effect and slow down the train.
• (More points to come)

Describe alternatives
If people dislike this, we can leave it as it is.

Additional context
None yet.

I suspect order glitches have more to do with corners and reloading.

I see this adding complexity, and we already have the Throttle Tracks which could be used to achieve this.

I'm not sure I understand how such a system would work. Like having the signals set speed zones? The current signal system would make such a thing clunky, but I think if I do rework the signals to use a graph it would pretty easy to integrate into that. I'm not really sure how a user would control the zone though.

The main problem with only applying braking effects instead of locking a train stopped is that will probably exacerbate a few other problems, like dead locks and collisions. I can see it opening a whole host of other problems that users won't understand very well.

Throttles only work on locomotives, and we don't know what speed level we need to set the throttle to.

Signals can just indicate the occupancy of a block (e.g. in China) or the speed limit (e.g. in the United States). If we had a remote signal network, it shouldn't be too hard to bind tracks to a signal block and retrieve speed limit information from that block.

Moreover, I am considering an idea of signal block with no shunting support. This means that the signal block only tracks carts in the entries of the signal blocks but is unaware of other parts within the block. This can somewhat simplify the signals; the no-placement restrictions are mostly complied by users in sp or antigrief plugins in mp. Of course, the status of these blocks can be controlled by machines and be forcefully updated in case of a disaster, etc. (like in real life)

The speed setting, in my opinion, would become additional fields to trains. Now, trains would have expanded functionality, including multiple speed limits and customized removals of certain limits at certain conditions.

If we had a remote signal network, it shouldn't be too hard to bind tracks to a signal block and retrieve speed limit information from that block.

Yes, that kind of lookup is a key part of my ideas for a graph based signal, so implementation would be basically free once we get to that point.

I guess what I need is a detailed (even if just a rough draft) of a ruleset for when speed should be increased/decreased.

And I'm still hesitant to make locking trains not an absolute stop, but without that, is this anything more than cosmetic?

To achieve gradual slowdown/speed limit, I now have a concept of train modifier:
these modifiers tick, but have an age or custom requirements to remove themselves

e.g. lockdown would add a modifier of about 10 ticks which slow down the train like the high speed transition logic to simulate a realistic stop
a block can add a modifier on speed limit that is removed when exiting a block to simulate automatic train protection

Gradual slowdown is cosmetic, yes.