> This is the top-down way, where say you have the tree
> (a (b (c d) e))
> You go like
> (a) -> (a (b)) -> (a (b c)) -> (a (b (c d)))...
> the way this one works is bottom up, kind of like:
> (a) -> (a (c d)) -> (a (b (c d)))...

I don't see that here - I assume that you made the configuration via
something like

C-x 3 C-x o C-x 2 C-x 2 C-x o C-x 3

or its orthogonal variant.  With your approach I do not see (a (c d))
after the second split but (a (b c)) just like with mine.  AFAICT your
algorithm performs exactly the same sequence of splits as mine.  You can
verify my claim by putting a 'y-or-n-p' after each 'split-window' call
(in the version I attached they are commented out in the code), making
two frames on your screen and stepping through your version in one and
mine in the other window.  You will see that they split windows in
exactly the same order.

I also noted that with

C-x 3 C-x o C-x 2 C-x 3 C-x o C-x 2

my and your last 'split-window' call split a parent window - something
you earlier told me that you didn't want to do.

The following is the central idea of my approach.  Suppose F is a first
live window (initially the 'frame-first-window') - a live window which
has no previous sibling in the window tree.  And suppose P is the parent
of F in the window tree that has already been deleted, all relationships
are from the tree before it has been deleted.  'delete-other-windows'
now deletes all windows but F.

  P
 /
F   P1    P2 ... Pn
   /     /      /
  /     /      /
 F1    F2     Fn

Now I take the next sibling P1 of F - I assume it's a parent window
because that's the hard case.  I find the first live descendant of P1
which is F1 (any parent window invariably has such a descendant).  My
first split is now

(split-window F .. (F1 . P))

because I see that F has not yet its valid parent P.  This resurrects F1
and makes F and F1 the children of the resurrected P.  If F already had
its valid parent P, I would have called

(split-window F .. F1)

and P would have got the additional child F1.  Now I recurse with F1
taking over the part of F.  After I'm done with the entire subtree of
P1, I do

(split-window P1 .. F2)

so P gets a new child window F2 and continue with F2 taking over the
part of F1 and F.  After I'm done with the subtree of Pn, I continue
with P's next sibling and go up until I arrive at the root of the window
tree.

Note here: Initially F's parent is nil.  When I split F to resurrect F1
both get the new parent P.  P is already the final parent of F but not
of F1.  When I later split F1 it will get its final parent as well.  In
neither of these splits, 'split-window' has any idea which parent window
to use.  It could try to find one among the dead windows the one whose
first child is F (or F1) but I haven't implemented such a mechanism and
I'm not sure whether it's worth the hassle.  That's why I have the
rotation routine initially remember the old parents of all windows and
pass them to 'split-window' as cdr of the REFER argument.

Note also that I always apply the new size to the window I split.  This
means that when I split F then F1 initially gets the entire remainder of
the size of P.  It also means that when I later split P1, 'split-window'
has to recursively resize the entire tree rooted at P1 and F2 gets the
rest of the size of P - that of P minus that of F and P1.

It might be interesting to try the following variant: Instead of
recursing immediately into F1, first split all siblings of F so that one
has a layout of

F  F1  F2  ... Fn

and only now recursively process F1, F2 ... Fn.  This would have the
advantage that when splitting F1 to fit in the entire subtree rooted at
P1, its size is already the final size.  And we might not have to split
parent windows either.  But such a solution will be less trivial.

Attached find my latest diffs (the documentation has not been completed
yet) and window-rotate.el.

martin