+Note [Overall plumbing for rules]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+* After the desugarer:
+ - The ModGuts initially contains mg_rules :: [CoreRule] of
+ locally-declared rules for imported Ids.
+ - Locally-declared rules for locally-declared Ids are attached to
+ the IdInfo for that Id. See Note [Attach rules to local ids] in
+ DsBinds
+
+* TidyPgm strips off all the rules from local Ids and adds them to
+ mg_rules, so that the ModGuts has *all* the locally-declared rules.
+
+* The HomePackageTable contains a ModDetails for each home package
+ module. Each contains md_rules :: [CoreRule] of rules declared in
+ that module. The HomePackageTable grows as ghc --make does its
+ up-sweep. In batch mode (ghc -c), the HPT is empty; all imported modules
+ are treated by the "external" route, discussed next, regardless of
+ which package they come from.
+
+* The ExternalPackageState has a single eps_rule_base :: RuleBase for
+ Ids in other packages. This RuleBase simply grow monotonically, as
+ ghc --make compiles one module after another.
+
+ During simplification, interface files may get demand-loaded,
+ as the simplifier explores the unfoldings for Ids it has in
+ its hand. (Via an unsafePerformIO; the EPS is really a cache.)
+ That in turn may make the EPS rule-base grow. In contrast, the
+ HPT never grows in this way.
+
+* The result of all this is that during Core-to-Core optimisation
+ there are four sources of rules:
+
+ (a) Rules in the IdInfo of the Id they are a rule for. These are
+ easy: fast to look up, and if you apply a substitution then
+ it'll be applied to the IdInfo as a matter of course.
+
+ (b) Rules declared in this module for imported Ids, kept in the
+ ModGuts. If you do a substitution, you'd better apply the
+ substitution to these. There are seldom many of these.
+
+ (c) Rules declared in the HomePackageTable. These never change.
+
+ (d) Rules in the ExternalPackageTable. These can grow in response
+ to lazy demand-loading of interfaces.
+
+* At the moment (c) is carried in a reader-monad way by the CoreMonad.
+ The HomePackageTable doesn't have a single RuleBase because technically
+ we should only be able to "see" rules "below" this module; so we
+ generate a RuleBase for (c) by combing rules from all the modules
+ "below" us. That's why we can't just select the home-package RuleBase
+ from HscEnv.
+
+ [NB: we are inconsistent here. We should do the same for external
+ pacakges, but we don't. Same for type-class instances.]
+
+* So in the outer simplifier loop, we combine (b-d) into a single
+ RuleBase, reading
+ (b) from the ModGuts,
+ (c) from the CoreMonad, and
+ (d) from its mutable variable
+ [Of coures this means that we won't see new EPS rules that come in
+ during a single simplifier iteration, but that probably does not
+ matter.]
+
+