After spending a significant amount of time fiddling with the first idea of actually inserting breaks as "special" jobs in TWRoute::route, I think this is not the right thing to do. The main interest was that all timing-related checks would work out of the box, but then we'd break the current meaning of the cost of an "edge" between two jobs in a route. If a break is involved, this cost would need to account for previous/subsequent jobs/breaks (sometimes at several level of distance), introducing a whole new layer of complex case checks whenever a travel time cost has to be evaluated. Considering this happens everywhere throughout the code-base, I fear we'd end up with an unmaintainable code.

On the other hand, if we don't include breaks directly in TWRoute::route but somehow remember where they stand, then the whole cost-checking thing can remain unchanged. This would shift the touchy part to the time-related checks and would require to:

• maintain a data structure storing break ranks relative to TWRoute::route
• take breaks into account for all timing validity checks (TWRoute::is_valid_addition_for_tw and is_valid_removal)
• take breaks into account for all route updates (TWRoute::add, remove and replace) and update breaks data

Also in case of several breaks for a vehicle at a given rank (think an empty route at the beginning of the heuristic), we need to account for the insertion position of new jobs with regard to breaks. The best way to do this is probably to expose this position to the above validity checks and update functions.

EDIT: I updated the task list accordingly.