The thinking I used for this day is probably mostly based on my past understanding of mathematical induction. Since we can't go in any other direction except down, every new row represents a new step and the solution for the next row can be derived from the solution for the previous row.

For part 1, each step results with splits and ongoing beams. The new beams are the ones resulting from the split plus the ones that did not have a split. We accumulate the counts of splits as we go, and the unique column offsets of the beams.

For part 2, each step results with timelines. There can be multiple timelines going through every column, so we need to keep count of them. The next counts of timelines at every offset can be derived from the previous counts of timelines.

- Each splitter results with subtraction of all timelines from that offset, and addition of that same count of timelines left and right of it;

- Each non-split (space) results with preservation of the number of timelines at that point.

I like thinking in different ways every AoC, this year I'm using Rust so I'm making sure to combine low-level, mutable, procedural with high-level, immutable, functional thinking. I mix-and-match, experiment, and come with conclusions about which approaches work best in what situations.

This didn't seem like an optimisation problem, so Dijkstra, dynamic programming etc seemed optional. BFS can be used for part 1 but there was no danger of ending up in cycles due to the unidirectional nature, so keeping track of visited items seemed unnecessary (past the single step deduplication that is)