To be clear, there is no bug here: derivers are simply not uniquely determined in the presence of fixed-output derivations, which is by design. That's even more true with CA derivations.
CA derivations also introduce the opposite situation, namely that the same derivation can produce different output paths for different users (if the build is not bitwise reproducible).
The deriver field in Nix has always been a misfeature. It was intended to provide traceability back to the Nix expression used to create the derivation, but it doesn't actually do that (since that wasn't really possible in the pre-flakes world, without hermetic evaluation). So instead it just causes a lot of confusion when the deriver recorded in the binary cache doesn't match the local evaluation result, due to fixed-output derivations changing.
In the future, Nix will hopefully gain proper provenance tracking that will tell you exactly where a store path came from: https://github.com/NixOS/nix/pull/11749
It refers to the new CLI, i.e. the "nix" command. The old CLI is the nix-* commands (nix-env, nix-store, etc.). The new CLI and flakes are still marked experimental, but the plan is to stabilize them and call that "3.0". So it won't be very different from the current 2.12 - you just won't need to enable some experimental features anymore to get the new CLI/flakes.
It's because Nix wants to install into /nix. Once upon a time doing "sudo mkdir /nix" wasn't a problem, but recent macOS releases have made that very hard.
Nix could switch to an alternate location on macOS (e.g. /opt/nix) but that has a lot of downsides for interoperability with other systems.
I'm sorry, but how exactly is this "amazing"? That you can find some bits to append to a number such that it becomes prime is rather obvious, given that there are an infinite number of primes and (probabilistic) primality tests are readily available. As other have pointed out, this is no more interesting than the fact that adding a "1" bit yields an odd number.
And what's the point? Yes, illegal information can be encoded as bits, those bits interpreted as numbers, and then you can apply transformations to those numbers. So what?
In NixOS (the Linux distribution based on Nix [1]) we use the functional approach for managing all the "static" parts of the system, i.e. packages, but also most configuration files in /etc - these get build by Nix functions in much the same way as packages. This is good since it means that (say) a rollback of the system will cause it to revert to a consistent combination of packages and configuration files. (So you don't get an Apache httpd.conf that refers to some feature that doesn't exist in the Apache you just rolled back to.)
However, when it comes to stateful stuff such as user data or databases, the funtional approach indeed doesn't really apply very well. NixOS manages state in an imperative manner in the same way as every other distribution. (For instance, NixOS uses Upstart jobs to create/update state.) That means that a rollback of your system won't rollback (say) your PostgreSQL database, unless somebody made the Upstart job of PostgreSQL do that. So when it comes to state, NixOS isn't better than other distributions, but it's not worse either ;-)
Feel free to try it out to see that it does, in fact, do this. No special magic is needed (most of the time): for instance, for dynamic library dependencies you can just set the RPATH at link time to indicate precisely in which directory an application should look for its dependencies.
Sure, eventually you run into scaling issues, but that's a first world problem.