If your filesystem is read-only, use ext2. That is proven stable for several decades, is fast, efficient, supports ownership, supports permission bits and has a huge user base as every Linux box supports it. In other words it supports everything a decent Linux system requires.
If read-only is not an option, your next best bet is ext3. Apart from all the properties that ext2 comes with, ext3 brings journaling. This means that every change on disk is only committed once it has actually been written to disk. Very stable, proven technology. A problem with ext3 is wear leveling.
Ext4 improves on performance in several use cases, but comes with more CPU overhead. Most distributions today default to ext4. Apparently it reduces unnecessary writes, which is good for an SSD. Ext4 has a TRIM extension.
Next in line it BTRFS. Don't go there. Although several distributions offer BTRFS or even default to it, it wasn't stable last time I tested it (H2 2012). You don't want to use a filesystem that hasn't proven itself under stress. Too many bugs are being fixed.
Linux offers a wealth of filesystems, but the ones I mentioned above are the most common ones.
Of course there is FAT32 (vfat), don't go there. It is old, it suffers from fragmentation and doesn't allow for ownership and file permissions.
NTFS is closed source, don't even think about it. Yes it kinda works on Linux but the implementation is fully based on reverse engineering (because Microsoft doesn't release any technical details) and the Linux implementation is just not reliable.
A JFFS2 needs to be entirely scanned on a mount, so mount time increases linearly with device size. This is caused by the fact that there is not some sort of tree structure to store files.
If interoperability with other systems is not required, your choice of algorithms will depend upon the resources you have available (most notably RAM) and your usage patterns. If you can get by with block-level granularity, and if no block will have to be rewritten too many times, the simplest approach is to simply map logical pages directly onto fixed physical blocks. Some applications are amenable to such an approach, but others are not. Generally, what is done is to have logical page addresses and keep a table of where each page is presently stored on the chip. When a page should be changed, a new blank location is selected for it, the data is written there, the location table is updated, and the old page is invalidated. If after such operation a block contains many invalid pages and no valid ones, erase it. If the number of blank pages gets low, the system should identify a block which contains many invalid pages and, move the still-valid pages to new locations in other blocks, and invalidate the copies in the old locations; once that is done, the block won't contain any valid pages anymore and may thus be erased.
There are many variations to this approach based upon things like the amount of RAM available for page tables, the amount of time one is willing to spend searching for pages, etc. If the number of pages is too large to keep a full table in memory, it may be necessary to store some of the table in flash. If this is done, it may be helpful to have a virtual mapping between logical block numbers and physical blocks, and have the "cleanup" operation find a new blank block, copy all of the valid pages from the old block to the corresponding pages in the new one, and assign the new block the same logical block number that the old one had. If one does this, one can avoid updating the tables that hold the locations of pages within the block.
Best Answer
I think it's a multi part answer.
I'd assume here that if a unit fails in the field you simply swap it out. The decision to scrap that board is then yours (how long do you WANT to keep the boards circulating). For your current boards you should have stock on hand of the NAND chips to allow for board failures and repair.
You'd produce future firmware that can support the 16bit NAND interface and whatever new storage interface you choose. For example in UBoot (if that's what you are using) you introduce the required drivers for the boot path.
I'd suggest using the SD/MMC interface (of which e.MMC is just one variant) since that can use a single lane to simplify changes. While speed is the concern for most MMC usage, it may be that you can tolerate a slower speed as long as it's consistent. You could use a single lane interface over SPI as an interface (about as simple as you can get). This might get you started thinking about it. Certainly this would seem to minimize changes to your PCB.