                           (go-right! ss)))
 	  ret (make-subproblem config nm (:input-sets left-sp) (:output-sets right-sp) nil 		 
 		(fn ri-fn [s ni]
-		  (refine-channel (:child-channel s)
-                   (make-half-pair-subproblem config (refine-input left-sp ni) #(refine-input right-sp %))))
+                  (make-half-pair-subproblem config (refine-input left-sp ni) #(refine-input right-sp %)))
                 (util/safe-get config :or-summarize))]    
       (sg/connect! ret ss) 
       (connect-ts! ss right-sp)
       (connect-and-watch! ss left-sp
-	#(publish-child! ret (make-pair-subproblem config % (refine-input right-sp (:output-sets %)))))    
+	#(publish-child! ret false (make-pair-subproblem config % (refine-input right-sp (:output-sets %)))))    
       ret)))
 
 (defn make-half-pair-subproblem [config left-sp right-fn]


;; Initially we are evaluated but have no children. (Lazy can be simulated by hierarchy)
;; Expanding generates and publishes child subproblems, based on children of subsuming if possible.



;; TODO: this assumes no inner child releases another inner child.  
;; Note: treatment of subsuming-sps was wrong in several ways ...
;; Right thing is: if not expandable, start fresh.
;; If expandable and expanded, do current thing (except, also wait on inner???)
;; If expandable and not expanded, do current thing
;; (problem is, inner bits may be hidden; may have non-correspondence).
;; TODO: all-child-channel!

(defmacro cache-under [dc ks body]
  `(if-let [^HashMap dc# ~dc]

;; Take dash_astar_opt_simple and add back complexities from
;; dash_astar.clj.

;; For now, just do single tree on (pess, opt) pairs. (or pure opt).
;; Ideally, would have separate opt & pess trees as well for caching.

;; Rationale for why we need this:
;; Suppose I have A, B.  Opt description of A has 3 branches of output.
;; Pess has single empty branch.  [-inf -inf] is valid description of this branch.
;;  i.e., doing things that way is effectively pessimistic about opt.

;; Can try to do this as: separate trees, plus "bridge" superstructure built on
;; top.  Or, as scaffolding which controls construction of lower trees.
;; Scaffolding seems preferable.

;; Also try to add real output collecting, since without it, any change
;; in a recursive hierarchy can trigger an infinite loop.
;; NOTE: output collecting is not really good enough, since any change in
;; recursive hierarchy can trigger infinite loop.  Need hierarchical
;; collecting of some sort.

;; Except this comes with problems of its own, loses current syntatic guarantees.
;; This really throws a wrengh in things, cause output things are no longer really
;; subproblems, shouldn't have tree summarizers (?), etc.

;; Solution to avoid huge syntactic/semantic mess of true hierarchical output
;; collection, and infinite loops of flat output collection:
;; - Only allow each to grow on a single step.  But, this is slow.
;; Impelemented: start new OC after input refined.  Don't add to OC if > reward.

;; TODO: RI of child not connected to child of RI.

;; TODO: put back bounding
;; (Currently asserting consistency in a sense, despite DM not having it.
;;  Causes some errors, e.g., with rand-nth.)

;; TODO: summary/+ should take order into account !  live iff left live or left solved, right live, ..

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;  Subproblems  ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(defn- make-subproblem
  "Make a subproblem with the given name and input-set.  If this is a wrapping
