bernie,

you're re-creating the "document model"
i use with my electronic-book programs.

my multi-media authoring tool "breeze"
-- which has been available from my website
for years, at www.performancepoetry.com --
is capable of doing the type of file-consolidation
that you are speaking about, for example.

even "rat" -- the rudimentary authoring tool for which 
i have recently been posting the source code here --
would be capable of doing it by putting the contents of
the textfile into the editfield and doing a regular "save".

you might have noticed i put the appleevents routine
in the last version i posted (the second), so now it's
the simple matter of one routine to read the textfile.

book-macway is also be capable of accepting any textfile 
dropped on it.  (as it is, i had to put in specific code that
rejects a file if it's not a specific type of listserve digest).

most of these textfiles wouldn't have the textlines present
that would be considered as the end of a listserve post, so
b-mw would put the entire file on a single page.  and of course,
you could re-program it so it automatically put one file on a page.

one thing you didn't touch on was simpletext files, and the fact that
they may be styled.  in this case, the text is stored in the datafork,
and the styling information is contained in styl resource #128.

(usually styled text is represented in a text/styl resource pair,
with the number of the resources indicated their pair resource,
in which case styl #128 should be paired with text #128, but
simpletext files are an exception here, so there's no text #128.)

in order to retain the styling information, which you'll wanna do,
read simpletext's data fork and save in a text resource, then read 
styl #128 and save it into a styl resource with matching number.

note that this paradigm can be easily extended to other resources.
so you could consolidate a number of pict files into one datafile,
by saving them as pict resources.  and the same with .snd files.

indeed, one of my early programs in this regard was called "vacuum",
because it could consolidate a number of files of different types.
i even made versions that, when run, would automatically examine
the files in the folder it was in, consolidate the ones it could, and
then automatically delete the files.  that's running a little bit too
close to the edge (moving the files to the trash would be safer),
but i can tell you, it sure was efficient at cleaning up folders!    :+)

like most all my programs of this type, e-book and otherwise,
"vacuum" stored the resources in its own resource-fork, not in
an external datafile.  and i think this is the best way to proceed,
at least on the mac -- i'm moving away from this model _only_
because i have to do so to go cross-platform, and move to os x.

speaking of vacuum, i am reminded that jim henson (remember him?)
actually wrote some similar apps, one which did just what you are
proposing, bernie, consolidated textfiles.  he did another for picts.
jim never was able to successfully send me either of his programs, but 
somebody has probably seen them.  i think he used external storage files.

but again, remember you don't need to write this program yourself,
as i've already done it, and "breeze" will do the job for you quite well.

***

gnome said:
>   both of these seem better than having a folder with 
>   a multitude of separate text files in it.

well, good, you've presented one of the reasons
i think breeze could be a useful app on anyone's machine...  :+)

-bowerbird