Honestly I was thinking the same. I've heard of this project years ago, but today it's only still reading NTFS volumes? For a project attempting to re-implement Windows?
I'm also curious about the two Program Files folders I see, identically named in the same folder.
My understanding is that NTFS support is fairly low on the priority chain; most windows features work just fine with FAT. I booted ReactOS into a VM a few months ago, and it ran many programs just fine out of the box, so it's come a long way since the previous time I tried it.
It's taken a long time for Linux to support NTFS fully as well. Not surprisingly, ReactOS has taken some time also. I think that's fair enough, unless you particularly enjoy filesystem corruption.
I think from the book "Show Stopper! The Breakneck Race to Create Windows NT and the Next Generation at Microsoft" by G. Pascal Zachary he mentions that NTFS was developed by an intern for the Microsoft PC system, on hardware that wasn't entirely finished, so, inexperienced file system developer + raw unbaked hardware + time pressures. This is going on an old memory, I haven't read that book since the late 90's.
Also throw in the fact that its proprietary and there is no specification or official test suite that I'm aware of outside of Microsoft.
The second one should be Program Files (x86). Perhaps the (x86) part is wrapped to a third line and not visible due to another window on top. Or perhaps the ReactOS Explorer shell's UI just cuts off the (x86) part (incorrectly). Probably not an issue in the NTFS implementation.
I'm also curious about the two Program Files folders I see, identically named in the same folder.