Here's my critique of FIT as it was, fogged by the mists of time and so probably a bit misremembered. See Fit List
I implemented a C++ version of Fit and got it to pass Jim's spec. It was really cool that Fit was intended to be useful for testing code written in multiple languages against a single document. I recall that my mapping of C++ to a Java software design that used reflection was painful and awkward. I had to throw every template, static constructor/destructor, and macro trick in the book at it to get anything approaching Java's implementation to work.
A FIT redo should be designed with more languages in mind, especially legacy ones that may have weak/no reflection or no object orientation. It should be as easy to register a Java class as a fixture as it would be to register a Visual Basic 6 procedure as one. Careful attention to the namespacing and type systems of target languages should allow tables to be mapped regardless of a target language's limitations. I don't have a complete picture on this, but I suspect the Fixture notion needs to be simplified to accommodate lesser and niche target languages.
That brings me to my second challenge with FIT: scope for implementations. Trying to reimplement the Java version in C++ was a huge challenge because of C++'s pitiful standard library string capabilities. Without bringing in a tortured tangle of 3rd party dependencies, I did not have regexes that I needed to parse HTML identically to the way that Java FIT did. I also recall the extensive use of exception handling in the Java version that I had to mimic was not C++ friendly, and my C++ runs were an order-of-magnitude slower than the Java version.
A FIT redo should have a greatly reduced footprint. No more parsing HTML in the target language. Ideally, a language implementation would be an agent or runner that would be configured or launched to connect to a server and talk in a simple text or binary protocol to the FIT server that any FIT implementer could support. The agent would be a dumb function caller and result/error reporter. The barest of bare requirements for implementers: open a socket to a configured FIT server, wait for binary commands to invoke a fixture function, write binary responses with results/errors from the call.
The core concept of having users save Word files with tables was clever but janky with all the saving to HTML, etc. It would have been rad if the FIT document editor was a webapp with nice document management, concurrent editing, and versioning features. I'm talking about a purpose-built rich text editor webapp that is fancy (and people will pay $ for.) Perhaps just an elaborate Confluence plugin if we don't to go all-out and build the whole editor from scratch.
A FIT redo should have a server that runs fixtures on all connected agents. It should produce business user-friendly, web-accessible dashboards with history and send email notifications for daily reports or when things go tail over teakettle.
Finally, I was happy to work with Jim on the original C++ implementation, but he asked me to assign my copyrights to Ward. Open sourcing code I write with a permissive license like MIT should have been enough to satisfy everyone's legal access to the code - instead we went all copyleft and viral with GPL. On a FIT redo, just like in the last go, I would keep the copyright under my name to any code I write as a point of pride, and I hope we could just do the MIT thang.
Speaking of pride, being able to say I work directly with Ward Cunningham on anything would be a pretty cool geek thing to claim. I don't know why, but Ward wasn't really involved on the last go, at least at the time I joined. On a FIT redo we should connect from time to time as a group over IRC or in-person at conferences just to shoot the FIT.