The robot prunes its intersection list as it runs (i.e. as it reaches a dead end and backtracks, it eliminates those dead-end intersections from the list), so it never stores the entire maze. This is sufficient because the maze doesn't contain any loops. In the end, what's left is the shortest path from start to finish.
That's much simpler and smarter than what I was trying to do. I was also taking a much more general case where the algorithm allowed any intersection to be reached from any other.
My algorithm would have handled loops in the maze though, but I never got to test it since I never had a way to read in the maze (the robot never actually got past the paper design stage).
I'd also like to make a line-following tutorial that explains how to use closed-loop PID control and a maze-solving tutorial that explains a basic algorithm for exploring a non-looped maze and for obtaining the best path solution in the process.
I'm really looking forward to reading that.
It's true, the 3pi has almost all of its I/O lines devoted to onboard hardware, which limits its general-purpose usefulness.
I was thinking more of having the standalone orangutan module to use in other projects while not playing with the 3pi.
But as far as what you did say, did you consider using port extenders for things like the reflective sensors to leave some general IO free?