That discussion doesn't seem very good to me, though there are some nice examples of Arc's notation at the bottom.
Our own kogir actually worked for a while on implementing Arc as a Racket language. It would have some advantages, especially around tooling. However, like all such platforms, Racket has a sweet spot (what's easy to build on top of it), and the further your semantics are from there, the harder it quickly gets. Redefining how null, true/false, lists, and macros work—as Arc does, relative to Racket—is not how a language platform is meant to be used! You end up fighting with it in a way that loses most of the advantages, and the difficulty seems to grow asymptotically as you approach 100%.
What you want instead is to stay in the sweet spot and let the underlying platform nudge the new language in all the directions that are easy to implement. The same is true of building transpilers—it's an order of magnitude easier when you can piggyback on the semantics of the underlying language. But this is not an option if your source language has already been defined elsewhere.
I think you're assuming that a language built that way would have to adopt Racket's underlying meanings for things, probably because Arc is, in the grand scheme of things, pretty close to Racket. But because Arc makes some fairly fundamental decisions that are different than Racket (such as how macros work), you can't keep those the same -- Arc macros can't be just Racket macros.
However, just because Arc can't be a layer of macros on top of Racket, that doesn't mean that the language can't be implemented as a Racket language. There are Racket language implementations of Algol 60, Python, and JavaScript, all of which are very different from Racket, more so than Arc is. And those implementations get the tooling benefits that Arc today misses.
It's easier to write a simple interpreter than a compiler, and Arc's current implementation seems to be working well for you, so far be it from me to tell you how to run your project. But certainly it could be implemented as a Racket language, no matter how far away it is.
"I wish they had implemented Arc as a Racket module language since then you could actually develop in DRracket, debug, and make executables."