Describe the bug

The documentation for nix-store --export says

This is like nix-store --dump, except that the NAR archive produced by that command doesn’t contain the necessary meta-information to allow it to be imported into another Nix store (namely, the set of references of the path).

My reading of this is that nix-store --export will also produce a NAR that has additional meta-information.

Steps To Reproduce

(pick an arbitrary nix path)

$ nix-store --export /nix/store/zyg9hz4vyfcz3ci7k7xbya4izxmcf8f4-python3.8-cffi-1.14.5 > out
$ nix-store --dump /nix/store/zyg9hz4vyfcz3ci7k7xbya4izxmcf8f4-python3.8-cffi-1.14.5 > out2
$ nix nar ls out /
error: bad archive: input doesn't look like a Nix archive
$ nix nar ls out2 /
./lib

Expected behavior

Both of the commands above would ideally work. Alternatively, nix-store --export should clearly state its output is completely incompatible with the NAR format and (ideally) indicate appropriate methods to manipulate these files (e.g. extract them to a directory, list contents etc).

nix-env --version output

nix-env (Nix) 2.16.1

Additional context

#3183 (comment):

But it's really the nix-store --export / --import commands that should be removed. They have a very wacky, non-extensible format that does not handle things like signatures and has other misfeatures (e.g. the metadata comes after the NAR, so on import we have to read the NAR into memory even though the store path may already be in the Nix store). So we should come up with a new format for storing closures.

Even this comment talks about NARs, which again gave me the impression I could use nix nar commands.