Well, I can do my best to summarize what I understand.

Moore has always intended Forth as sort of a stone-soup language- a collection of ideas and techniques that can be taken from and recombined to suit different purposes and programmers. There were several efforts to standardize Forth and build it out into a language with formalized, extensive libraries (ANS-Forth, mainly), but they are largely antithetical to Moore's attitude of continual experimentation and refinement.

The current state of the art with ColorForth is pretty alien in comparison with ANS-Forth. It's an exercise in subtractive design. The most obvious change is that the ColorForth environment tokenizes input as it is typed. Tokens can have some metadata associated with them which is reflected in their color. ColorForth generally uses colors to eliminate the need for the "mode switching" words in a normal Forth- comments, [] "compile-time blocks" and colon definitions, for example. By pre-tokenizing source code, virtually all the string manipulation required in the compiler is removed and getting rid of mode-switching words makes source code more compact visually.

The F18 core and the GA4/GA144 chips based around it are incredible machines. In a nutshell, an F18 is a tiny Forth machine with 64 18-bit words of RAM which can be packed with up to four instructions apiece. The GA144 has 144 F18 cores which communicate with their neighbors via a blocking handshake mechanism. Thanks to both to Chuck's novel approach to chip layout and simulation and the fact that there is no global clock, the GA144 uses very little power compared to other CPUs and microcontrollers with comparable compute capacity, despite the fact that the GA144 uses essentially antique fab technology. With no changes to the design and the latest fabrication techniques you could (theoretically) get an order of magnitude more cores on the same sized die and drive power consumption down further.

Programming the beasts is another matter. Since each core has very limited space for code, programs tend to have the character of functional pipelines in which each core takes a few arguments from neighbors, possibly stores a small amount of local state and computes simple functions to pass down the chain. I think that if any language other than Forth could be compiled for the machines it might be an array processing language like APL. Even if the resource constraints weren't difficult, simply getting your program deployed onto the grid is tricky, since you can only directly talk to cores on the edges- you have to write code that "walks" through the grid of F18s, pushing code into neighbors and triggering them to do the same, establishing communication channels and then tearing them down as they are replaced by the final application code.

So where does this put us? GreenArrays has extremely energy-efficient, highly scalable supercomputers-on-a-chip, but programming them is very difficult and requires incredible attention to detail. There are a number of PhDs in the making solving the new problems in compiler technology this type of architecture raises. If GreenArrays was open to the idea (and they seem to be), a more portable software simulator of the GA144 and more accessible development tools (ie, tools that do not require booting a Windows VM and learning a new keyboard layout on top of the ColorForth language) could be a huge shot in the arm. If a killer-app emerges that can take advantage of the power consumption and the particular style of parallelism the chips are capable of, these designs could change everything, but the jury's still out.

...Does that help at all?