The best value I see in it are the fixes you can apply to vfp9.exe, too.
In the end, I think that's almost like using VFPA 32bit. This also has additional benefits, as we saw in some threads, lately, like larger FPT files allowing to store more in Memo or Blob fields without fearing the 2GB limit, even in each individual field.
The only thing that already has bugged me a few times is VFP's fuzzy handling of longer strings than officially documented and in the new-to-me memo bug even relatively short memo contents. I can live with such things, as long as there are workarounds or even better alternatives as is COPY MEMO in case of storing memo content to a file.
I don't feel that good with the patching update process, and the lack of issue tracking as was pointed out by Rick Strahl in the link Tore Bleken posted, I already also pointed to Rick Strahl's comments in another thread:
As it's April now, the downloads work for a while again, I actually will try to get it going to take a look into how far you can make use of longer strings in a meaningful and performant and consistent way. It's not necessary to have longer strings to be able to use FILETOSTR() or STRTOFILE(), though, and just as an intermediate vehicle from memo to file or vice versa, I also don't need long string support. Windows API allows handling larger files, too, by the way. So far I could always mitigate problems with long strings by changing the processing to smaller portions, even with performance gains.
Otherwise larger DBFs are also not really a solution to scalability issues, you have a better benefit of changing from DBFs to a SQL server backend, overcoming the 2GB limit is not the end of what's needed to enable everything you can have with other databases, like better partitioning of data and other index types or even completely different storage concepts. The major benefits of DBFs are also string in smaller DBFs, so overcoming the size limitation is almost counterproductive.
I think my almost namesake Christof Wollenhaupt has understood one thing better than any other effort to continue VFP development: If there are bugs, they are mainly in the runtime, not in the byte code the build process makes of VFP source code. So the future of a continuation of the VFP language isn't in patching the IDE mainly, but in developing a new runtime. The VFP C compiler from Chen, therefore, is the best he has to offer in the package. Not because of its core feature to mix in C++ code, but to get rid of dependencies of the older C++ runtime versions and to keep VFP up to date on that level. The usual vfp9r.dll or vfp9t.dll are still also just patched versions of those original DLLs as VFPAR.DLL and VFPAT.DLL, so it's only an advance on the lowest level of C++ dependency but would allow having a more consistent development of FLLs using the same C++ runtime versions as the VFPAR.DLL runtime and that's a slight plus.
I'm also not sure about the legality of all of this and not confident MS will always look away just because they have "bigger fish to fry".
Chriss