There seem to be two variants in the field on what a NAND driver
should do. All-in-one systems make the NAND driver look just like a
block device and handle all the ugliness of block remapping, erase
unit handling, wear leveling and garbage collection in the driver.
There are at least three commercial NAND packages that work this way.

This allows you to hide most of the NAND issues from the filesystems
and put just about any sort of filesystem above the NAND, but doesn't
allow you to perform all the FS level optimizations that you might,
and makes for a lot of complexity in the driver. The commercial NAND
packages seem to export additional functionality to allow FS writers
to take advantage of NAND's peculiarity by providing transaction
support.

The other sort of system makes the NAND driver a
sort-of-block-device-with-extras and exposes the raw NAND interface to
the next level, usually through a block device driver for the
'ordinary' blocks and the  use of ioctls for the out-of-band data and
handling erasure.

The advantage of the second approach is that it allows you to take
advantage of NAND oob data for data structures used by the filesystem.
I'm familiar with a couple of filesystems that use this attempt, YAFFS
on Linux and a modified LFS on a commercial OS.

In either case, it's a good idea to separate the driver into a logical
NAND component and a set of device-specific function for driving the
specific NAND part.

> 2. Is anyone else either interested in this, or working on it?

Yes. I am.