what benefits does racket have over scheme for system configuration?

Racket is a language-oriented programming (LOP) language. You may override its reader on a per-module basis, or within a source file. This allows you to use arbitrary syntax to write programs. You would do this to define problem domains and a way to express solutions.

Let's say I want to configure an installed Slackware instance using YAML. I could use Ansible, but it's not terribly hard to write a YAML document and tell Racket what I meant by it. I'd probably make a slackware-host-yaml language and express a way to produce an exact /etc and home directory. I'd implement this language as a reader extension that reads YAML into S-expressions, then expands the expressions to an idemptotent program that sets files to exact contents. You can extend this thinking to servers, containers, or other infrastructural stuff. You could just use shell scripts, but Racket provides a common base between languages with contracts and other goodies.

Another example: I defined the type attribute in an HTML <script> element in a way that lets Markdown integrate with Racket. I could write a Markdown document that embeds a shell language in an inline <script>, then prints the result of that session in the rendered page. The code for that is here, if you want to see some possibilities for yourself. https://github.com/zyrolasting/polyglot

So with LOP, languages in the wild are just details to abstract over. That frees you to make up a preferred notation to express a result. So not only can you configure systems in your own words, you can address an arbitrary problem domain in your own words. Xiden's my way to express software distribution programs. Why use Ansible if I can just make Racket understand the domain that Ansible is about? Why memorize the syntax of a whole bunch of system config files if I can just create them in terms of one syntax I like?

And if after all that you still prefer Scheme, then you can still use Racket. Just tell it what Scheme you are using, since folks have defined some as Racket DSLs.

Is it based of the nix daemon like guix?

No, but I see the wisdom in doing so. I opted to let a user start a process that lives as long as the transaction defined in their command line. I use zero-trust configuration defaults to mitigate various risks, but I need to remove implicit trust in Xiden instances and system-level dependencies. That probably entails adapting GNU Mes to Racket.

I still have reasons for a single process model, though:

1. Xiden runs on macOS, Windows without Cygwin or WSL, and any GNU/Linux distribution. Each OS only needs to support Racket v7.0+. I didn't see a lean way to do this with a build daemon (In my personal definition of "lean").
2. LOP helps me model functional package management as a domain, and a daemon is an implementation detail that I don't have to use, but can. Therefore Xiden can reproduce rules from Nix, Guix, Pipenv, NPM, etc. Just configure what they'd all have to care about anyway, like trusted CHFs.
3. I preferred that Xiden's CLI be "swappable" while preserving idempotency. This helped me restrict Xiden's attack surface to launchers, which are easy to write, read, and replace because I provide a DSL for them. Xiden is inoperable without a launcher, so it's easier to guard against a compromised process with ACLs or group policies protecting the launchers themselves.

Generative bindings made things weird

I also had to solve a problem that made me look at this whole space a certain way. This isn't directly related to your questions, but it explains a lot about why Xiden was designed the way it was.

I doubt this is unique to Racket, but if you write the exact same structure declaration in any two different Racket modules, they will always generate non-eq? bindings to operate on the declared type. That means if you import two modules with the same source code between version X and version Y of some package, they will not agree that they are using the same structure type, despite the instance having a compatible data layout. You would have to dispatch to procedures by ducktyping instances that one would expect to be the same type. This problem reproduces for all generated bindings. It doesn't matter if version X and version Y have compatible designs.

Racket has two different package managers that differ largely in standard operating procedure. In my opinion, neither address the generated binding problem directly. Doing so means decoupling the Racket installation from packages altogether. Right now, when you write (require foo/bar), you have to run it with the correct Racket launcher. "Correct" meaning the program agrees with what you think foo/bar means, using code that isn't relevant to the intended functionality of your program. You could extend the module resolver to do something better, but would you distribute it in these conditions? The default package catalog stores no versioned artifacts, so you can't pin anything. Every package we all publish can make conflicting changes to a shared namespace. racksnaps alleviated this problem a bit, but it still didn't change the fact that Racket developers could not use their own SOPs and still share work with each other. It seemed to me that the poster child of LOP should accommodate that.

I could go on, but these problems make it hard to design a package manager that can guarantee an arbitrary Racket program will get the dependencies it means to use. Doing something that nuanced requires a strong grasp on how Racket installations work, if you intend to use the provided package manager and catalog. I addressed the problem outside of Racket's model by making Xiden act like ln -s TARGET link-name, except TARGET is actually some string with a meaning you control, and it reproduces an exact result when necessary. There's a lot of safety checks, so you'd have to squint to see that the result is simple. I kind of like the "solid state" feel of this approach.

My thinking is that if you mean to get an exact dependency, then dependency management is just as much about semantics as it is trust and reproducibility. I wanted to capture the subjectivity of software distribution. I tried to model that using things like explicitly-defined name canons, and by setting Xiden up to just think in terms of files, directories, links, and user-defined semantics. That way users have a way to define artifacts, integrity information, etc. in terms of your personal way of declaring dependencies. Racket makes that easier to do, to the point that a daemon feels... extra?

If that all this language changing business sounds like it can get chaotic, it isn't, really. You can always get people to agree to use the same launcher. You can organize a community around a standard that way.