This is slightly related to the write strategy discussion, so I'll
hijack its thread. While rebasing my layout patch set I rewrote the
layout file parser. It is now more flexible and it would be easy to
support more features. One feature it does already support are comments
starting with a # (anywhere in a line).

ATM it parses all previously valid layout files (AFAIK) and it should
continue to do so, even if they are not too common yet. We do not know
the exact numbers of usage, so breaking an unknown number of systems
does not seem like a good idea. We could and should provide a script
that converts 1.0 files to 2.0 syntax though. That should be trivial
anyway.
One way to guarantee compatibility would be to have two modes of
operation in the parser and to mark layout 2.0 files somehow. This way
we could make sure that old formats are always handled correctly without
making it hard to add new features. The marks do not need to be backward
compatible IMHO (would be hard and/or awkward to do anyway because the
old format is so limited). So in case we need it I propose the
following mark:
Layout 2.0 files have to start with a comment in the first line
including "flashrom layout 2.0" (which is trivially implementable:
skipping whitespace till # in a loop, find the string with strstr
(and rewind)).

NB: Currently everything after the first space is considered the name of
the region. A typical line in 1.0 looks like this:
00009000:0003ffff normal
and it cant look much differently.

Things I definitely want to see in 2.0 files:
 - Comments. :)
 - Replacing mandatory hex with auto-detected address range bases.
   While probably everyone will use hex numbers I dont see a reason why
   we should enforce this. Converting 1.0 files by adding 0x in front
   of the addresses is easy to do too.

Other possible features (just food for thought):
 - Default image names. For example one might want to always use me.bin
   for the ME region without the need to specify it all the time on the
   cli. (add the name after the region name, separated by : just like
   in the cli)

 - Default inclusion status. It would be nice to be able to mark some
   regions as to be included by default so that one does not even need
   to use -i. (no idea about syntax yet)

 - Includes of other layout files (include .*)

 - Some kind of priority if one selects overlapping regions.

Comments and further suggestions very welcome!

My current plan is to use the modified parser which parses the old
layout file without a problem but includes comments in my first batch
of layout patches. That consists mostly of the known patches to add
read, erase and verify support for layout files + that parser patch +
what else I can implement before the batch gets merged, but probably
without any other features discussed in here.