Reported by Anton Prowse
There is a general class of issues regarding the fact that the automatic, fixed and height layout algorithms desperately try to be agnostic to the particular borders model being used, but do not satisfactorily succeed.

i) 17.5.2.1 (Fixed table layout) talks vaguely about borders.  In the case of the the collapsed borders model, is it referring to the border lumps made up of cell and column borders?  (See also Bug 17133.)  In the case of the the separated borders model, there are no column borders to consider; are the cell borders accounted for when determining the column widths (since columns contain cell borders in this borders model)?  Cf. Bug 15460

ii) 17.5.2.2 (Automatic table layout) also talks vaguely about borders. In the case of the separated borders model columns are supposed to contain cell borders, yet that doesn't seem to be the case here unless the "minimum cell width" in steps 2 and 3 of the column width calculation refers to outer width; this would be in contrast with how that term is defined in step 1.  It looks as if the algorithm is simply assuming the collapsed borders model.

iii) 17.6.2 (Collapsing border model) doesn't talk about horizontal borders (other than table top and table bottom) and 17.5.3 (Table height algorithms) merely says:
  # A value of 'auto' means that the [table] height is the sum of
  # the row heights plus any cell spacing or borders.
More explanation might be needed here.

Conversation begins:
Bug description:
http://lists.w3.org/Archives/Public/www-style/2012Jan/1016.html (Issue 6 b,c,d)