diff --git a/TODO b/TODO
index d17860e55d2099b67df0f3b89bc6a67f74b538d1..47cfd23dadbebb55cdc288d0110362c42d36adc6 100644
--- a/TODO
+++ b/TODO
@@ -1,21 +1,67 @@
-* Decree that versions older than 2 years are not supported,
-  maybe remove them from upgrade tests
-  (or split upgrade tests in two test sets: short and long).
-  We should already not support anything older than 2.019 or so
-  (still used by LispWorks).
-  Yet, we should keep supporting upgrading from what vendors provide
+* Decree that versions older than 2 years are not supported;
+  yet, keep supporting an upgrade from whatever vendors provide
   — so push them to provide recent stuff.
+  Already, swank-asdf doesn't support anything older than 2.014.6
+  (as provided by the first 2011 iteration of Quicklisp), and
+  I (fare) am pushing for swank-asdf to not support anything older
+  than 2.019 (still used by LispWorks 6.1).
+  Hopefully, sometime in 2014, everyone will have adopted ASDF 3.
+  Maybe remove old versions from upgrade tests; or maybe not:
+  if we support old versions in any way,
+  it should be for upgrade only, and "punt" is acceptable.
+  Upgrade tests might be split in two test sets: short and long.
 
-* Moving toward cross-compilation (ASDF 3.2?)
-   This would allow to get all or most of the benefits of XCVB
+* Moving toward cross-compilation (ASDF 3.2? 4?)
+   This would allow to get most of the benefits of XCVB
    (reproducibility, scalability, applicability to mobile platforms, etc.),
    except without the backward incompatibility of XCVB.
+   NB: the MOCL author would benefit a lot, and might chip in.
 ** Need to further split asdf:perform in two parts:
    A part that runs on the host and specifies (as SEXP or string to read)
-   a form that must be evaluated on the target machine, not the host.
-   A trivial that runs on the target and doesn't require the network
-   of objects related to the ASDF plan to be present,
-   or even ASDF itself, for the matter (though UIOP, yes, for sanity).
+   forms that must be evaluated on the target machine, not the host:
+   (asdf:perform-forms target operation component)
+   The default implementation can fallback to running the
+   (asdf:perform operation component) on the target,
+   which if it is on specially crafted operation and component objects
+   that do not require recreating the component hierarchy and plan,
+   but still require loading the defsystem-depends-on dependencies:
+   on the target:
+
+   (defmethod perform-forms ((target null) operation component)
+     ;; null target designates current image
+     `((asdf:perform ',op ',comp)))
+   (defmethod perform-forms ((target external-target) operation component)
+     ;; external target means a cross compiler
+     `((require :asdf)
+       (map () 'asdf:load-system '(,defsystem-deps))
+       (asdf:perform ,(fake-operation-form operation)
+                     ,(fake-component-form component))))
+
+   The other way around the default perform method could be:
+
+   (defmethod perform ((o t) (c t))
+     (let ((forms (perform-forms nil o c)))
+       (if (equal forms
+                  `((asdf:perform ',o ',c)))
+           (error "Missing perform method on ..." ...)
+           (map () 'eval-thunk forms))))
+
+   Note that in the general case, there are multiple forms,
+   that must be provided on the command line somehow
+   (see the lisp-invocation system and also how cl-launch does it),
+   with packages necessary to read latter forms being
+   created by former forms, so you cannot read everything in one go.
+   ASDF or at least UIOP should probably be provided in the target
+   image by default, anyway, without needing to be explicitly specified.
+   A more declarative interface to needing the defsystem-deps
+   is probably useful.
+** A real cross-compiling backend that works the way of XCVB
+   would need to compute a complete graph for the plan,
+   which could be achieved by inheriting from the code in POIU.
+   Thinking about it, the cross-compiling target object
+   could actually be the same as the plan object.
+   The basic case of in-image execution would need to be in ASDF,
+   while the actual cross-compilation case would be in an extension.
 ** Audit all the current specializers of perform, and offer them a new way;
    they can keep the perform method to run on older versions of ASDF.
 ** Modify SBCL and other implementations so they provide UIOP
@@ -95,9 +141,11 @@
 * fix directory-files to not return directories on CCL, etc. Add tests.
 
 * use cl-test-grid to see if asdf-user can :use most (all?) of UIOP.
-  Unhappily, on SBCL, sb-grovel uses asdf and sb-ext,
-  which causes a clash with run-program.
-  Or has this been changed long enough ago? Can it be special-cased?
+  SB-GROVEL used (until 25c1769 from 2013-02-23) to :use both ASDF and
+  SB-EXT, which prevents ASDF from exporting RUN-PROGRAM, but
+  should not be a problem with ASDF-USER :use'ing UIOP.
+  A run of quicklisp is necessary, with an eye also for warnings
+  from .asd's that might be overriding definitions in UIOP(!)
 
 * have a mode to explain WHY a component needs to be recompiled.
 
@@ -236,7 +284,7 @@ It looks like SWANK can be fixed soon, though, so we'll see.
 *** com.clearly-useful.generic-collection-interface => :com.clearly-useful
 *** metatilities
    => :ait-timeout :system-applicable-p
-*** ucw ucw-core 
+*** ucw ucw-core
    =>
    version
 
@@ -247,6 +295,7 @@ It looks like SWANK can be fixed soon, though, so we'll see.
 
 * deferred-warnings support probably needs to be redone better.
   * implement deferred warnings support on lispworks
+  * turn undefined function style-warnings into full warnings(?)
   * work with cl-test-grid to eliminate deferred warnings from quicklisp libraries
   * https://www.mail-archive.com/asdf-devel@common-lisp.net/msg03608.html
   * czak@google.com rewrote part of deferred warnings support.