Based on experience developing for PalmOS, and Linux on ARM devices
and now learning my way around DangerOS, a few observations:

NOR and NAND flash don't really fit the same abstraction. I think
there's a lot of unnecessary overhead in Linux-MTD because it tries to
be all things to all flash. I'd suggest being careful trying to
abstract to bridge both.

There's a signficant tradeoff as to where you do the bad block
management, block remapping, and garbage collecting.  If you put it in
the filesystem, then you limit yourself to only file systems that know
about the flash related issues.  This means that you get a lot of
reinvention done as each new file system is adapted to using the
device.

While there are some performance disadvantages, I believe that such a
system really needs an intermediate layer that provides a logical
block device interface to the file systems and handles bad block
management, et cetera.

for nand flash, the standard operations seem to be:
configure/get configuration
read/write in-band/out-of-band
ecc
and
erase region

There are two approaches one can take, either treating the out-of-band
region as separate and using two file descriptors, or handle the
out-of-band read/write with ioctls.  I have no opinion on which is
prefered.  I assume the config, ecc, and erase stuff would be handled
via ioctl.

There aren't any standard partitioning schemes for "MTD" devices.
uboot and redboot each deal with paritioning differently, for example,
which is why the Linux MTD layer has mapping.

There are, I think, three ways to go about file systems for such
devices, once they've got an interface in place:

1) (Most of the commercial NAND FSes do this) put most of the smarts
in the block device layer and put an ordinary fs about that. (Bonus
points for adding transaction-like capabilities.)

2) The jffs approach: understand the limitations of the hardware and
embed a lot of knowledge into the FS data structures, but avoid the
out-of-band regions.

3) The yaffs approach: like jffs but use the out-of-band regions for
the extra data.

Yaffs allows you to be more clever about how you use the device, but
is subject to changes in the nature of the out-of-band area. jffs is
currently slow. hopefully jffs3 will fix that.