You must be talking about a different software then.
Actually we (i.e., all the creators) face two challenges at once:
1) Make the game do something close enough to what it ought to do.
2) Make the player overlook the difference.
In the case of markers (for platforms, sidings, etc.) there is the visual representation - the track work - and the logical layer - the marker.
I can easily figure out an innocent programmer (the type that created the rest of the code) determining the following logic:
If there is an uncoupling activity and if the train (the whole one) is on a marker (as a whole) and if this marker features on the to-do list as uncoupling and if all the listed wagons are among those that are uncoupled, then tick off that item on the to-do list.
The evil inside me wants to see if it is enough for the engine, but not the wagons, to be on the marker when you uncouple.
Also remember that the game often does not see wagons you coupled to the engine during the scenario. In such a case, my evil theory might have a chance to prove true in practice.
However, the original problem was that on passing the marker, you get faulted before you get a chance to uncouple. This may be half connected to the innocent logic I described above and half to the game not expecting the player to return.
In either case, having long markers could help. Sure enough they are not prototypical then, but this is a game looking like a simulation under favourable circumstances.