It's a bit of both, though much more spiritually. A low-level component (the daemon) is taken from Nix. The daemon takes so-called derivations (text files listing the expected outputs and inputs, as well as the file name of the builder script), sets up a chroot where the inputs are available, and runs the builder script. Everything above that level of abstraction is different. (Guix has first-class package values and build system abstractions, for example, and is generally implemented as an extension to Guile Scheme, i.e. as an embedded DSL.)
Even at that level there are differences: our build scripts are not glued together shell snippets but Guile scripts that are generated from the upper layers.
We're in the process of replacing the daemon with something written in Guile, because a lot of the daemon's functionality has already been implemented in Guile for other features of Guix (e.g. the container features), but we're in no hurry as the modified nix daemon works fine in practice. We'd love to reuse more Guile code, though, and lower the barrier to hacking on the daemon (which is currently written in C++), so eventually the only thing that connects Guix and Nix is the format of the derivation files and the idea of functional package management.
Even at that level there are differences: our build scripts are not glued together shell snippets but Guile scripts that are generated from the upper layers.
We're in the process of replacing the daemon with something written in Guile, because a lot of the daemon's functionality has already been implemented in Guile for other features of Guix (e.g. the container features), but we're in no hurry as the modified nix daemon works fine in practice. We'd love to reuse more Guile code, though, and lower the barrier to hacking on the daemon (which is currently written in C++), so eventually the only thing that connects Guix and Nix is the format of the derivation files and the idea of functional package management.