Hopefully, then, the following will clear up any lingering confusion. Start with this, here. 20 cells.

Combine cell 1 in rows 2 and 3, and also cell 3 in rows 3 and 4.

Now cell 4, for rows 3-5.

These tables, of course, do not have clearly fixed cell widths and heights, established by graphics of a certain size, as before. These are just cells with text in them. And the text can vary in size, in line height, and so on.
 
Combine a few more, including a couple spanning columns.

Rows three and four become ambiguous, so extra cells on the right are needed to establish those rows, in this case for both Microsoft IE and Netscape. In the previous example, an older version of IE could calculate height because fixed heights were used for all cells. Here, the text in the cell determines the cell's size, unless table cell width and/or height are specifically given. So . . that's why. The spacers, here, just use 'new row' tags (<BR>), three times (that is, three blank lines per cell), based on the height of the current font.
 
Combine the center cells.

And, of course, if you also span cells 1 and 2 on row 5, you lose the definition for column two. So, a row 6 has to be added for column 'spacers'. The width of the first cell is already established above. So cell 1, row 6, just gets a blank line. The text in cell 2 is used to re-establish the width of column 2. Again, for a carved up image in a table, fixed cell widths and heights would make this all more exact. And the spacers on the right, and the one on the bottom, would be thin transparent .gifs that you couldn't see.
 
Note, too, that the colspan on the top was changed to 16, a number way beyond the number of columns, here. It doesn't expand that much because the extra columns are undefined, essentially blank. What extra width is added is the result of adding up the little space used between the cells, here. But the table is looking for 17 columns, in all. In fact, in IE 5 and NN 6, the columns seem to be determined by cell tags (<TD>), and the extra cells/columns of the large colspan, here, are ignored. But NN 4.7 will expand out to the right.
 
In other words, it's clear when using text where the table boundry is. The colored areas, if your browser shows colors in the cells here, can be thought of as what you'd see as a sliced up image in a table, when borders are not shown on the table. And if the spacers, previously and in the home page graphic, were not transparent, they'd appear sort of tacked on (as in the top of page 3 example).
 
And a minor note: while it might seem a trivial design problem, it's good practice not to leave any space on a line between close of the image tag, or whatever is in the cell, and the close of the table cell. PSP 7's image slicer handles this properly. But if you do this yourself, with a text editor, from the table reference mentioned, previously, you know that </TD> is the close for the table cell. If the cell contains just an image, say, then the closing bracket, >, for the anchor tag, or for the image tag itself, should be immediately followed by the close cell tag - i.e. ></TD>, and not > </TD>. That extra space will cause the table not to 'close up' properly, believe it or not.
 
And so . . with nothing further to add, I just hope this has shed some light on what at first might seem, as it did to me, a bit confusing.