Okay, I found another problem with the RAMDISK. I decided to see if I could force it to use FAT32, so I did:
RAMDISK min=2200 R:
While in the QSINIT shell, it said it did it. When I boot OS/2, it hesitates for a second, or so, and reboots.
I need to do more work with this. Something is missing, somewhere.
Yes. I was able to reproduce the problem using a real disk. It is not the WPS that is doing it wrong. The drive must be in the proper format when OS/2 is booted (probably when the IFS is loaded).
I formatted a real partition as FAT, and it failed to work properly (it was JFS previously). I got errors when trying to copy a file, with a LFN to it. I then rebooted, and it worked as expected. Okay, so I formatted it to JFS, and it did exactly what the RAMDISK does. Reboot, and now it works properly.
It seems that you will have to create the proper format in QSINIT, to make it work properly, or make the drive removable, so it can be remounted, after formatting (not too sure how that will work, since it cannot be physically removed).
Unfortunately, FAT format is restricted to using short file names, even if the WPS can use long file names. That makes it of very limited use, and it won't work properly for the %TEMP% directory, unless every program happens to use short file names for the temporary files (which is, apparently, not the case). HPFS has serious problems. JFS, on the other hand, seems to handle the situation, and it does work, for most things, but very odd errors will pop up every once in a while when the WPS stores files with short file names. Hmmm. I wonder if that has something to do with the larger cache that JFS has. If the file is still in the cache, it might be retrieved with the LFN, while the file system has put the file on disk with the short name. I hate to think what that might do.

You say that FAT can be used for the swap file. I don't doubt that, but a swap file is only used with small memory configurations, which would rarely be the case when using QSINIT. There are very few other things that a FAT RAMDISK might be good for.
I would note, that HPFS is probably required for those who do not have bootable JFS. I don't have the old IBM JFS any more, so I don't know what might happen with that. The new bootable JFS works best, but can have problems because the WPS will write short file names, when it shouldn't, and the underlying support doesn't know that it should have a long file name.
FAT32 might actually work better, because the IFS is loaded later, and it already has LFN support. I doubt if it could be used for the swap file, but it might be usable for %TEMP%. Since it already has LFN support, at boot time, changing the format might work better.
If MPTSTART.CMD called from config.sys - it works.
Here one shot with such HPFS disk: WPS, command line and FC windows.
It does NOT work. A reboot, with the proper disk format, is required for the IFS to recognize that it can use LFN for the file names (and directories). You may also be seeing the cache, not the hard disk.
You can format it with small cluster size, for example:
format c: /a:4096 /f:1 /q
just after ramdisk command.
Hmmm. That lets it boot, but the disk does not finish formatting to JFS, and the system hangs. The disk is 895 meg, on the system where I am testing. I will try without the format to JFS step. Yes, that seems to work, the FAT32 drive appears to work properly. Now, to try a format to JFS. No, that doesn't work. It is probably some sort of restriction in the FAT32 driver. I will need to experiment with using FAT32 for the %TEMP% directory.
I will need to find more time later...