Indeed, this is getting off topic, but we might want to have a separate
discussion sometime about the "FITS data model" and perhaps even how
to map this into more flexible serializations or storage mechanisms.


(also, as a matter of history, FITS began as an image transport format,
and tables and image extensions came much later).

Yeah, I am uunfortunately old enough to remember that (even enough
to have written random groups) ;-). Tables were the first extension
I think, then the image extension.

The basic FITS model provides a keyword table (PHU or some other form
of empty image kludge), an N-dimensional image object, a table, plus
a simple general container (the MEF). We can aggregate instances of
these three basic objects in a container, an associate them in some
fashion to model more complex objects, such as instrumental datasets.
Usually this is done by defining a convention, e.g., using custom
keywords in the PHU and/or extensions.

Well, that's one way of looking at it. The alternate perspective
that I am arguing for is that everything should go into one table
extension, with images as either multiple entries in one row
or entries in successive rows. Essentially, that's the perspective
that's taken by the Green Bank convention for sets of radioastronomical
spectra.

One can argue that Table can contain anything including an image,
but the regularly sampled N-Dim Image case is so important that it
deserves its own class. If nothing else, this is still required to be
able to efficiently store and access large data arrays.
Actually, storage and access inside a binary table is perhaps
slightly more difficult to get right, but it is just as efficient
as using image extensions (if anything margiinally more efficient,
due to less block padding).

In addition,
the basic Image object is much simple than Table, and much existing
code can do useful things with a FITS image, but cannot do anything
with a FITS table.

That's definitely a factor that needs consideration. For DENIS
we used a large binary table to store stripes of 180 1kx1k images,
but ended often/usually working through a filter that extracted one
image to a FITS file because a tool expected that. On the other
hand, that format did provide very robust consistency (stable
header items in extension header, variable ones as element of
the data rows, and nothing ever duplicated).


Within VO, FITS is still the preferred format for image data, whereas
VOTable is often used instead of FITS for table data. One could
argue that the FITS Image is the most successful and widely used part
of FITS, and even today provides a better mechanism for storing and
manipulating regularly sampled data arrays than anything existing
alternative.

Simpler and most successful for sure. Better, that depends on what your
goals/criteria are :-)