Red is not compatible with Rebol3, due in part to the fact that development on Red started before Rebol3 was open-sourced. The binaries for Rebol3 at the time were too unstable, so the older and much more solid Rebol2 was chosen. There is a major undertaking underway currently though to refactor and fix large portions of Rebol3's core code. Which will then be rolled into the community edition and also hopefully the corporate sponsored Atronix fork. Also there is some talk going around about packaging and integrating TinyCC with Rebol3. IMO both projects show alot of promise, and have many progressive ideas.
The irony is that some core concepts in Rebol have been borrowed into the mainstream, the trouble being that people just don't realize it. Rebol was a major influence on JSON. Crockford used to be active in the community, and had really hoped for an opensource Rebol. Carl, who created the language didn't want that, so Douglas created JSON instead, as a way of bringing some of the concepts of Rebol's Data Exchange Dialect to the opensource masses. One regrettable thing is that the there was a definite loss in the syntax and semantics by making what would become JSON intelligible to Javascript.
The syntax is minimalist for a reason. The primary paradigm of languages in the Rebol family (like Red) is language-oriented programming of which creating domain specific languages in an important factor. The more minimalist the base syntax the less you force the end-user into a syntactic corner, when they go to design their own DSL's. As for blocks (those things delimited by brackets) they're technically a data-structure (actually all code is an implicit data structure). In Rebol for example all the typical control flow structures are actually functions which take as arguments vectors of code.
The compilers for Red and Red/System are written in Rebol2. The binary distribution is just an encapsulated Rebol interpreter with source code. Rebol2 needs the 32-bit supporting libraries.