A few thoughts on this discussion.
GTFS-static has no concept of "pattern" while nearly ever transit agency is deeply involved with patters or variants. Some agencies even include a "pattern" file in their GTFS export (ex. MBTA has "route_patterns.txt").
In the hierarchy of transit:
-Routes are a collection of patterns.
-Patterns are a collection of timepoints and stops with waypoints (i.e. shape).
-Trips are a sequence of timepoints operated by one or more runs/duties (i.e. mid-route relief)
-Blocks are a collection of trips from pull-out to pull-in.
The fundamental link between trips and patterns is that every unique sequence of timepoints from the schedule must match a pattern. There can exist, and often do, more patterns than are used in a schedule (unscheduled short-turns, summer patterns, school variants, etc.). Dealing with these unscheduled patterns is often a huge challenge in analysis as there is no schedule to "hook" to for predictions or performance. It might be nice to at least work them into the GTFS-static feed for geometry.
GTFS-static also does not have a concept of timepoints, as everything is managed via stoptimes.txt and trips.txt. (Ahem... we might want to have a concept of a timepoint flag field in stoptimes.txt, but I digress.) Most working with GTFS data build "patterns" or variants out of the stoptimes data along with shapes and trips.
I see a few solutions on the surface:
1. Add a route_patterns.txt file and link via a shape_id field. Store direction and possibly extra headsign data in the patterns file. (storing headsign data within the concept of patterns is beneficial for locations that do not change the sign mid-trip)
2. Use the existing shapes.txt file to add a direction_id field that maps to a more human understood direction (ideally lowercase sans "-bound", that is north,south,east,west,in,out special case for counter and clockwise : one might suggest standard numbers such as used for route_type)
3. Expand the current use of direction_id in the trips.txt file. It is already binary 0/1, but could be made into a short integer to represent direction (N,S,E,W,in,out,up,down,clock,counter)
Each of the above have benefits and limitations. Suggestion #2 probably is the least disruptive, which is key for such an established standard. Why touch more files than necessary or mess with a critical field?
I look forward to working with more GTFS-static data as my current experience is limited to the CTA (nearly a decade off and on) and now some MBTA work.
Thank you for reading these thoughts, I am excited to follow the evolution.
--Mike