Simon,
As Sumit said, we use dynCompileExpr for core functionality of IHaskell. I am not really sure how the change you are proposing affects that, though.
We use dynCompileExpr in several places for evaluation inside the interpreter context:
1. Evaluating a Haskell expression in the interpreter context, converting the result to a ByteString, then using fromDynamic to extract the bytestring and convert it to a value in the compiled context.
2. Getting a file handle from the interpreter context to the compiled context; this does not actually use dynCompileExpr because there were some bugs with dynCompileExpr and so I had to literally copy source from InteractiveEval to reimplement parts of dynCompileExpr (unrelated: the issue was that dyncompileexpr imported and then unimported Data.Dynamic, and this messed with data declarations that had already been created in the interpreter context)
3. Extracting IO a values from the interpreted context to the compiled context so that they could be run; this is necessary to get displayed values from the interpreter back to the compiled code.
I think two of our uses, which are both very central to the way IHaskell works, would be impacted by requiring a Binary instance (or similar), which is what I think you are proposing (since we have two uses at least where we marshall `IO x` values via dynCompileExpr, which cannot be serialized, I believe.)
I am sure that there are alternative ways to do what we are doing, but they are probably not simple and would take quite a bit of work.
-- Andrew