Currently, we include the store directories in store paths in JSON. This makes for nice-looking JSON that is easy for humans to manipulate.

However, it comes at a cost in that it breaks almost all JSON frameworks somewhat: the store dir is not actually part of the store path data type, and so it must be smuggled in somehow. We work around it with ad-hoc code in C++, but in other languages the expectation is for JSON to be very "regularly" defined, e.g. with traits/type classes, and so forcing things to be ad-hoc carries a higher costs.

Here are some options:

• Just don't include a store dir any more. The JSON would like like e.g.

  "0nxvi9r5ymdlr2p24rjj9qzyms72zld1-bash-interactive-5.2p37"
  

• Parse any store dir. As long as the path ends with the store object file name, and isn't something like /nix/store/0nxvi9r5ymdlr2p24rjj9qzyms72zld1-bash-interactive-5.2p37/bin/bash, we can just peal off all leading directories and just parse its "basename". but in the to-JSON direction, we still need to come up with a store directory out of thin error. That breaks the languages infrastructure.

• In fancier languages, do the moral equivalent of StorePath<"/Nix/Store">, which allows us to smuggle in the store dir at compile time. This works, but leaves less fancy languages in the lurch. It replaces one source of intimidating complexity with another.

• Just do nothing, because we care more about the human case than the machine case.