Defining the TDS required many compromises. Both the overall structure and the details of the individual directories were arrived at by finding common ground among many opinions. The driving forces were feasibility (in terms of what could technically be done and what could reasonably be expected from developers) and regularity (files grouped together in an arrangement that "made sense").
Some interesting ideas could not be applied due to implementations lacking the necessary support:
The TWG settled on the `format/package' arrangement after long discussion about how best to arrange the files.
The primary alternative to this arrangement was a scheme which reversed the order of these directories: `package/format'. This reversed arrangement has a strong appeal: it keeps all of the files related to a particular package in a single place. The arrangement actually adopted tends to spread files out into two or three places (macros, documentation, and fonts, for example, are spread into different sections of the tree right at the top level).
Nevertheless, the `format/package' structure won for a couple of reasons:
The TWG struggled more with the font directory structure than anything else. This is not surprising; the need to use the proliferation of PostScript fonts with TeX is what made the previous arrangement with all files in a single directory untenable, and therefore what initiated the TDS effort.
We considered the supplier-first arrangement in use at many sites:
texmf/fonts/supplier/typeface/type/
This improves the maintainability of the font tree, since all files comprising a given typeface are in one place, but unless all the programs that search this tree employ some form of caching, there are serious performance concerns. For example, in order to find a `TFM' file, the simplest implementation would require TeX to search through all the directories that contain `PK' files in all modes and at all resolutions.
In the end, a poll of developers revealed considerable resistance to implementing sufficient caching mechanisms, so this arrangement was abandoned. The TDS arrangement allows the search tree to be restricted to the correct type of file, at least. Concerns about efficiency remain, but there seems to be no more we can do without abandoning subdirectory searching entirely.
We also considered segregating all font-related files strictly by file type, so that METAFONT sources would be in a directory `texmf/fonts/mf', property list files in `texmf/fonts/pl', the various forms of Type 1 fonts separated, and so on. Although more blindly consistent, we felt that the drawback of more complicated path constructions outweighed this. The TDS merges file types (`mf' and `pl' under `source', `pfa' and `pfb' and `gsf' under `type1') where beneficial.
We considered having the `mode' at the bottom of the font tree:
texmf/fonts/pk/supplier/typeface/mode/dpi/
In this case, however, it is difficult to limit subdirectory searching to the mode required for a particular device.
We then considered moving the `dpinnn' up to below the mode:
texmf/fonts/pk/mode/dpi/supplier/typeface/
But then it is not feasible to omit the `dpinnn' level altogether on systems which can and do choose to use long filenames.
The TDS specifies using a single directory `modeless/' as the mode name for those utilities which generate bitmaps, e.g., `texmf/fonts/modeless/times/'. This has the considerable advantage of not requiring each such directory name to be listed in a search path.
An alternative was to use the utility name below which all such directories could be gathered. That has the advantage of separating, say, `gsftopk'-generated bitmaps from `ps2pk'-generated ones. However, we decided this was not necessary; most sites will use only one program for the purpose. Also, PK and GF fonts generally identify their creator in the font comment following the `PK_ID' byte.
We are making an implicit assumption that METAFONT is the only program producing mode-dependent bitmaps. If this becomes false we could add an abbreviation for the program to mode names, as in `mfcx' vs. `xyzcx' for a hypothetical program Xyz, or we could at that time add an additional program name level uniformly to the tree. It seemed more important to concisely represent the current situation than to worry about hypothetical possibilities that may never happen.
We considered placing additional documentation files in the same directory as the source files for the packages, but we felt that users should be able to find documentation separately from sources, since most users have no interest in sources.
We hope that a separate, but parallel, structure for documentation would (1) keep the documentation together and (2) make it as straightforward as possible for users to find the particular documentation they were after.