I am going to try to explain my ideas for the dynamic assignment system. But to be super clear: the most important aspect of this design is that it preserves all the current order system elements as they exist in 1.13 and it is entirely opt-in. If you never flag stops as allowing schedule changes, and keep the schedule shift train sets as a single train, never repeated, you get Schedules 1.0 and your trains never dynamically change schedules.
How is a train assigned to a shift? Let's think about the easy case: a train has been just purchased, or has just been intervened. In this case the train is empty of pax and it has no location on the map, therefore it is valid to be assigned to anything. If this train is then put in the allowed set of trains of some Schedule Shift, and that shift becomes available, the sim can assign the train to the shift. Its state will then change to running a shift, the schedule system will record that particular shift as being taken by the train, and then it can be spawned at the right time and at the right stop for the current time of the day. This is not very different from the current system, it just has an extra step of adding the train to the shift train set.
To make shift assignment a powerful feature it must allow for dynamically changing a train schedule and shift, even if said train is already spawned. Some red lines must be traced to make this happen. First, the train must be stopped at a line stop to be eligible for schedule change. Changing a train schedule while it is running leads to chaos, since its track reservations become different. Experienced players will immediately point out that this is just as true when the train is stopped at a line stop. Yes, it is, but since it's a line stop, if you get chaos it is immediately obvious you need to signal it properly, at least an exit signal at the platform. In fact this should be a requirement to allow for schedule changes, and I will think about ways to enforce it.
Another clarification: changing the shift/schedule of an already running train never means teleporting the train. A train can only change its schedule if the new schedule would also timetable it at the same time and location it is already.
So if now, somehow, trains are capable of changing their schedule when they are at a line stop (with an exit signal), what happens to the pax? The second red line is that only technical stops can be allowed to change a train schedule. Such as it makes no sense for pax to plan to ride a train beyond a depot stop, it should make no sense for pax to plan a path beyond a stop where the train is capable of changing its schedule.
Therefore, like pieces of domino falling one after the other, the dynamic shift design calls for 2 new features: being able to flag individual line stops as allowing trains to change their schedule (staying in the current line must always be an option if no shifts become available). But this is then equivalent to flagging individual line stops as technical stops, rather than whole lines. This is because I would like dynamic assignment to not be too restrictive, so for example setting up a whole depot line just to allow for a schedule change at a terminus station during the day is too much. So you should be able to stack a second stop (or more) on the terminus and flag it as allowing schedule change, without the train changing platforms.
But currently such stacked stops are always simplified down to a singular stop. So in 1.14 train AI must finally do the right thing and "run" stacked stops as singular events. In the earlier example you could have a 3 stacked stop in the same platform (replace "platform" with "main platform and all secondaries"): train arrives at stop 1 and waits for 1m for pax to leave the train. This is a pax service stop. Then stop 2, set up in the same platform, is marked as technical + allowing schedule change, for an hour. Then stop 3, still on the same platform, is pax service and allows the boarding of pax. This could model a train with dwell time at a terminus, with just a single line. Then at the schedule level you could end the line order at stop 2 to make it wait for as long as you need during the day, so you could have rush time schedules and base service schedules, and trains could dynamically jump between them when at stop 2.
How, exactly, I haven't decided it yet. The previous example and design are obvious: if a train is stopped at a technical+assignable stop, then it should be able to be reassigned to a shift which is not currently timetabled as a technical assignable stop, as long as the train state matches it in time and location, and no train is running it.
And no train is running it? This doesn't sit well. Since this 1.5 design preserves 1.0 semantics for orders, a train entire week is always planned. In 1.0 by train orders filling an entire train week with runs. In 1.5 by schedule orders filling an entire shift week with runs, because for backwards compatibility, 1.5 schedule orders are identical to 1.0 train orders. Sure, some stops might be flagged as assignable, but it's still the case the shift covers the whole week. So after all trains are spawned, they all have a shift assigned, so unless you have more shifts than trains, they will just sit there running their already assigned shift, since there's nothing to switch to.
Having more shifts than trains does not match well with the current design of the game, but it does match real life better. It requires a total rethink of what a shift is, compared to a 1.0 copier train. A shift would represent some assigned train time, rather than being a time shifted version of a whole week worth of orders. I could see it making it work if for example shifts allow to select orders to disable them, so shifts are expressed over a subset of the Schedule Orders, representing singular days or even singular runs, with most of the week time as a padding stop in a assignable tech stop. This could work, but it would end up being very different from the current copier concept.
At the moment I am not sure how to proceed with respect to dynamic assignment. In any case there's a lot of work to do which does not depend on it. Making Schedules its own top level game object and editor is alone worth it, so if dynamic schedules end up being too complex or different they could be left out.