Arc is a pretty small codebase built on Racket, so I think if there's an answer to "Can Racket be used to write an OS?" then the Arc answer follows close behind.
I can imagine two distinct ways you might be interested in OS development, so I'll answer twice. :)
---
Personally, when I think about writing an OS, I'm motivated mainly by the prospect to design new ways that "applications" can be obtained, upgraded, and integrated with each other.
I would not want to develop low-level memory management code and device drivers. That would open up a can of worms in terms of security issues, not to mention the expense of keeping up to date on the latest hardware and the latest machine-code-based security topics. So my "OS" would ideally sit on top of another OS kernel.
For that kind of application, Racket could be great. Racket has tools for running computations in sandboxes with limited memory, so it should be practical to run a new kind of "application" this way as well. Looks like there's a way to run any X Window System client program as a kiosk (https://raspberrypi.stackexchange.com/questions/11866/how-ca...), which can probably be used to run a Racket GUI application. So it seems like all the tools exist to make a Racket program take the place of an OS desktop and manage its own applications.
Since Racket has these sandboxing and GUI features, technically Arc can invoke them too, since Arc can run Racket code. However, I don't think I've seen anyone use these features in Arc code yet, so it might be easiest to learn them in the context of writing a program in Racket itself.
---
On the other hand, if your goal is to do things that involve machine code, kernel privileges, and device drivers, you'll pretty much want a language where the run time semantics is very similar to machine code, with the ability to refer to specific memory addresses and the ability to initialize and manipulate its own call stacks. In many cases where you're using functionality specific to an architecture, such as booting up and initializing a first call stack, you'll need to write assembly code so that you know precisely what machine code is being generated.
There are many "C replacement" languages out there, but the one that I consider most approachable right now is Rust. It's easy to find a number of tutorials and examples of OS programming in Rust, and Rust is sort of a codification and streamlining of many techniques that have caught on in C, so the skills may be somewhat transferable between those languages.
---
In short: Racket (and hence Arc) has a lot of the high-level tools for making OS-like systems, but it's probably not good for the parts of an OS that require meticulous attention to machine code. I recommend something like Rust for those.
What OS skills or projects are you thinking of pursuing anyway? :)
I know of 2 examples of Lisp being used to develop an OS (there may be more): one by Symbolics (called Genera) and the other by Lisp Machine Inc (aka LMI). Apparently both of these descended from code developed at MIT's AI Lab. Googling, it sounds like some of the source code for one of the versions was released as open source.
Of course, Lisp Machine Lisp (or Zeta Lisp, et al.) are not the same as Arc, but I expect that what you can do in one, you can do in the other. Small matter of programming :-)
The interesting question is not the implementation language, but what you intend to build.
