Tracking issue for all the things that would break compatibility

[roberth]

Is your feature request related to a problem? Please describe.**

Some changes can't be made because they break compatibility with older Nix.
Users have certain expectations that we don't want to break. After all Nix is supposed to be reproducible.
This is a very significant requirement that rightly affects many design decisions, but also prevents some seemingly insignificant issues to be fixed.

I am not proposing that we actually go ahead and break things. Instead, we may use this issue and the "breaking" label to at least gather and categorize issues that we can't act on, or can't fix completely, etc. This is like a tracking issue, but expect no progress. It might be useful if a "major update" of Nix will be considered in the future, but we'd first have to run out of worthwhile improvements to make.

Describe the solution you'd like

(Describe alternatives you've considered)

(not sure if we want to track alternatives here)

Store and Build

• Various simplifications of the derivation format. We could create a new format, but we'd have to support the old one too for compatibility.
• Input addressing existing at all, or
  • Assuming it does exist: Path Infos not linking to path infos. I would want fixed Nar hashes for the entire closure / recursive
    content addressing for validation purposes, even if the store path is still determined from inputs not content.
• NAR hash -> merkle tree (feasible as addition??)
• Store paths having names at all
• CA field in path info referring to content but not references

Language

• Path interpolation is implicit. This leads to a surprise every now and then. Instead, a non-zero but lightweight syntax could have been chosen.
• Path interpolation produces base names containing a hash. Instead, a store directory containing the original filename could have been created. "cp ${./script.sh} $out/" would work as expected.
• type = "derivation" -> _type = "derivation"; although this may be a happy coincidence for attrsets that have both traditional derivation attributes but also a redesign set of "package" attributes that does not necessarily correspond to a single derivation. They may carry both type tags.
• All type coercions (weak typing bad), or
  • Remove outPath in favor of toString
• baseNameOf only strips one trailing slash when the argument is a string. Details: Test and document builtins.baseNameOf, improve internal baseNameOf() #10306
• "\u1234" == "u1234". Unfortunately this doesn't throw an error, so we can't just assign a different meaning to the sequence \u. (e.g. to make the solution to builtins.toJSON impossible to create single backslash followed by certain characters #10082 more ergonomic)

Additional context

Priorities

Add 👍 to issues you find important.

[Ericson2314]

added

This might be too big but:

• input addressing existing at all
  • Assuming it does exist: Path Infos not linking to path infos. I would want fixed Nar hashes for the entire closure / recursive content addressing for validation purposes, even if the store path is still determined from inputs not content.
• store paths having names at all
• CA field in path info referring to content but not references