Of course in border areas, you may have to deal with neighboring country's coupling (and other standards) and there were time periods when you had to deal with transition from one braking system to another, but that is IMHO too much of micromanagement and complication for players.
I do also think so for pak sets that try targeting everyone, including beginners. However, the beauty of the system would be that it's possible. So if one day someone wants to create a more complex pak set for advanced simu players, there's nothing stopping him to do so.
I don't know if such a pak modification would be played by many players but trying to solve things differently is always a nice things for experience exchange.
In regard to ICE2 and similar - we had some similar discussion in pak128.sweden forum: http://forum.simutrans.com/index.php?topic=15851.0
In general you have two options: either you want to follow the reality very strictly, and then you have to define all 8 cars as separate objects (and further 8 for reversed unit). Or you give your players some freedom, and allow them to build something that really does not exist, but is technically possible (i.e. longer/shorter, without dining, over/under powered, etc.) In the latter case it may be beneficial to have a constraint group for ICE2 so that only ICE2 cars can get coupled together and pak developers are free to make a fictional ICE2 car (e.g. mail).
I do currently have that exact problem with some closed source MU paks that fit the balancing well but don't have mail so these just aren't used, so I guess I will drop these out of my list of addons. This affects nearly all SNFOS and ENASSA MUs that were not made by Gauthier.
Also, newer MUs that don't have power heads anymore can most often also be configured by the client to fit different lengths. However, there are in fact requirements between the cars like powered cars that need to get the power from another car carrying a transformer and a pantograph.
The point is that if someone made an SJ Dm or NSB El 12 pak back in the 1950s, and put screws coupler constraints on it. An player in the 1970s would not be able to use that locomotive in Simutrans to pull knuckle coupled cars, even though the real locomotive was doing that in real-life. But this is more of a design rule than a technical issue, because the style of constraints I propose/support, could technically be used to create a screw vs. knuckle coupler constraint. There is however a significant compatibility issue with such a different constraint concept.
For st-ex it should not be a problem. The SJ Dm or NSB El 12 just has a screw coupler constraint in the 1950s and there will be an upgrade changing screw couplers to knuckle couplers availiable in the 1970s.
For sure to do so there must be a way of changing constraints by an upgrade.
For st-classic we would indeed need something like "or" connected constraints that can use constraint groups. The currently implemented constraint system is "or" combined, so we could maybe just combine it with constraint groups. That way we can't say that te train can just pull knuckle cars from the 1970s on but it would be a fine compromise I think.
We could just say constraint[next]=screw-coupling, constraint[next]=knuckle-coupling and could couple everything that can provide a screw-coupling or a knuckle-coupling.
Opposed to this, requiring something means, that everything of the requirement list has to be given otherwise the train can't move.
What about the option feature I mentioned?
That would be some kind of automatic vehicle upgrade if the requirements are given.
For example if a car has an engine option, that one can be activated by providing enough electricity to that car by forwarding the electricity from some electricity provider.
Also if there is a steam heating option in that car, that one will be activated if a car nearby can provide the heated steam.
Btw. groups of couplings can already be simulated in Simutrans by creating a coupling as a dummy car. That coupling is given the list of all cars that do have the same coupling and the cars will only contain the couplings it can use as the prev/next constraints. That way we do still have to maintain a long constraint list but we do only have to maintain it once for each coupling type instead of once for each car. Anyways, this is ugly and will decrease maximum train lengths pretty much. I guess this is the reason why pak authors don't define couplings that way.
Btw:
Your whole ICE2-concept is flawed, because you want to require players to do what you would like to see, pretty much arbitrarily.
You obviously didn't get what I want to do. Enforcing the dining car was just another compromise that worked best for all of the 4 mentioned aspects except the freedom for players to create whatever they want as long as it stays balanced.
I do just want to get as close as possible to trains that can
-be composed by the player as he wants, especially including over-length trains.
-be composed in a realistic setup without being worse than any unrealistic composition for its primary use case.
-not be composed in a way so that the train is completely unrealistic and also the best for a secific use case. That means it's np for me if someone creates a train that has only dining cars, but it is a problem for me if that is the most profitable configuration for a specific use-case.
-be build symmetrically, because otherwise some players will start crying again. However that point is the least important one for me nor I want to enforce symmetry for all.
For sure if there was a comfort level this would also be easier but by choosing constraints in a specific way, it's also possible to get close to these 4 points without a comfort system but currently the constraint system is a way too inflexible for really doing this.
That being said, I won't be writing about my balancing thoughts in this thread nor I will give any examples that are not explicitly about technical rrequirements.
Just notice that a more complex constraint system would make some things easier.
Anyways as I said, it was just an example that isn't that bad imho because a system that can describe these requirements well can also describe technical requirements well.