Postgres restore unclear behaviour
With regard to your questions, please read the documentation completely, as it addresses all of your concerns.

In terms of looking for 000000010000000000000018 when it doesn't exist .. the recovery process just parses all WAL files until it encounters "EOF" .. which usually happens when it tries to read from the next WAL file and it doesn't exist..  So it uses that case as a termination point for the recovery process..  The important bit here is that it reached a checkpoint in the recovery process as stated with consistent recovery state reached at 0/17000160.  This means that your recovery is reliable.

Continuous Archiving Documentation Section 24.3.5. - Timelines

Timelines are a way for Postgres to handle "alternate universes" so to speak...  For example, if you have a situation where your replication gets messed up in some way and suddenly you have slave promoted into master status (while your master never went down) ... some machines are writing to the master still while some are writing to the slave..  But it's ok, because the writes to the current master will all happen on timeline 1 and the writes to the slave will all happen on timeline 2 .. so you can, theoretically, still merge all the changes together (although I'm sure it wouldn't be easy)..  I imagine it's similar to a branch in a version control system.  Except there's no real "trunk".

For the postgres gurus out there - if I have anything incorrect, please correct me.  :)