I hacked up the analyser to "fix" this by changing the lines at line
473 onward to read:
{{{
if isTopLevel top_lvl
then fn_ty -- Don't record top level things
else case dmd of
Box (Eval (Poly Abs)) | DmdType _ _ res <- fn_ty,
returnsCPR res -> addVarDmd fn_ty var (Eval (Poly lazyDmd))
_
-> addVarDmd fn_ty var dmd
}}}
So if we demand a CPRish variable (such as bound by a case scrutinee
or a U(LL)-demanded lambda-binder) in the evalDmd then I throw away
the Box part of the evalDmd on the basis that after CPRing we won't
demand the box at all.

I doubt this hack is the right solution (and I haven't tried it to see
how it affects the libraries) but perhaps it gives you some ideas.

== Infelicity 2: a case where demand summarisation hurts us ==

I found practical examples where summarising the demand transfomer of
a function as a single strictness signature hurt us. The examples were
code like:
{{{
h :: (Int, Int) -> Int -> (Int, Int)
h x y = if y > 10
then x
else h (case h x 0 of (y1, y2) -> (y2, y1)) (y + 1)
}}}
If, at the innermost use of h, we re-analyse h in the demand
C(C(U(LL))) rather than just unleashing the vanilla DmdSig computed
from the demand C(C(S)) then we can unbox the pair argument. Currently
GHC just gives h the DmdType SU(L) which doesn't eliminate the
allocation of the pair at all.

A scheme like in "stricterness more relevant" but with let-binding
that is polymorphic in the use-site demand might be able to detect the
extra strictness here. I think Stefan Holdermanns has a paper
describing such a system. But this is anyway much harder to fix than
my first infelicity.