See the whole thread at NixOS/nixpkgs#16130 plus the ensuing IRC discussion.

As a quick recap: I and several other people see IFD as a pretty important prerequisite for Nix's continued growth, but there are a few technical issues standing in its way right now that we don't have clean answers for.

What we'd like to be able to do:

1. Write a Nix codegen that takes in locked-down inputs from (presumably) a fixed-output derivation
2. Incorporate the output of that codegen into nixpkgs
3. Be able to use nixpkgs sensibly in that state, and have it lazily reach out to a cached output of the autogenerated nix expressions with little-to-no degradation of user experience

What hinders it right now:

1. Restricted mode prevents network access which stops this from working on Hydra today
2. Full understanding of ramifications of this approach:
   1. Is UI unfriendly when we have to build stdenv or similar during evaluation?
   2. Should channel bundles include subchannels or allow fetching them on the fly?
   3. Is it now harder to understand what a nixpkgs evaluation involves, and whether a rebuild will be necessary? Definitely, but we could write tooling...?
3. Do substitutes work properly during evaluation?
4. What happens with multiple levels of evaluation->building->evaluation->building? This is unlikely to be a real scenario but it might happen by accident if someone's codegen depends on someone else's ecosystem.
5. What happens when a stdenv itself depends on one of these things? The darwin stdenv uses llvm, which depends on python. It currently doesn't use any pythonPackages but who knows what might happen in future?
6. Policy: when do we want this? When do we not want it? How do we make sure it's used in reasonable ways?
7. [More things I haven't thought of]