Well, it was proposed, and a few board members were receptive to the idea, but that's not a final decision. Just to be clear, the Board's job is to manage the administrivia of community infrastructure, like servers and mailing lists. Setting the development agenda falls the community at large. 

I think the best way to introduce Filesystem in the base image would be to include just the core packages (FS-Core, FS-Disk, FS-Tests-Core and FS-Tests-Disk), and leave the others as optional, loadable additions. That core would be sufficient to cover all the functionality provided by FileDirectory, and parts of the system that deal with files can be gradually migrated over. 

I wrote a couple of paragraphs on why it wouldn't make sense to have an implementation FileDirectory as a layer on top of Filesystem, but then I came to the conclusion that it might not be a bad idea after all. The devil is in the details, and we ought to look into the details. Either way, the current implementation of FileDirectory should eventually be available as a loadable package, so that we can still build images with legacy code that depends on it.

Also, I wanted to point out that FS-AnsiStreams is basically obsolete. I wrote it because FileStream and friends couldn't be adapted to work with non-disk filesystems, and I wanted to have a single, uniform interface for reading and writing files, regardless of the type of filesystem that contained them. But then I discovered that Xtreams already does a way better job of that than anything I could have written. There might be some value in FS-AnsiStreams as an ANSI-compliant portability interface, but AFAICT, no dialect supports this part of the ANSI standard correctly anyway, so it wouldn't be much use.

FS-FileStream is more useful, but it's only meant as a stepping stone. It lets existing applications use Filesystem for navigating around the directory hierarchy (which should be a fairly easy port from FileDirectory) while continuing to use FileStream for IO. It provides a FileStream-like interface for IO operations on non-disk files. (Ultimately, a modern application that does a lot of IO should use Xtreams, though. It's a tremendous improvement over FileStream, SocketStream etc.)

So really, the optional bits are FS-Memory, FS-Zip, FS-Git (by Max Leske and Camillo Buni), and FS-Xtreams. 

Also, to address Chris' point about tiny images, it would be possible to split FS-Core into two packages, one with just the minimal functionality and then another with the advanced features. I don't think that's a high priority, since we don't have a core image of the size where FS-Core would make a difference. But If/when we do get there, I don't think Filesystem will be an obstacle.

Colin