Current output of prooftrees:

@SašoŽivanović Actually, there's a bunch of false=1s first, but they're obviously merely a bonus offer.

Looks charming! ;-)

@SašoŽivanović Indeed. I definitely think it is an improvement over previous versions.

@SašoŽivanović How can I change the processing order? The manual says that this must be done in a nodewalk. But I want to put it in a style and saying for nodewalk... there doesn't work at all happily.

\forestset{%
  define long step={proof tree proof first}{}{%
    if line numbering={%
      c2,descendants,fake=o,1,descendants,
      if justifications={fake=o,3,descendants}{}%
    }{tree},
  },
  proof tree 2/.style={%
    for nodewalk={before typesetting nodes processing order/.style={proof tree proof first}},
  }
}
\begin{forest}
  proof tree 2
  [#1,l sep=0,for n=1{
      l=0,no edge,delay={enumerate=#1}}
    [
    [[[[][]][[][]]][[[][]]]]
    [[[[][]][[][]]][[[][]]]]
    [[[[][]][[][]]][[[][]]]]

I think the definition of the step is OK because I tested it with your enumtree thing before trying this version. (It didn't quite work initially, but it seems to work correctly now.)

I can't figure out how to order the delays correctly and there aren't enough stages before nodes are set. So I thought maybe if I could change the order of processing, it would be easier. (This isn't the only reason it no longer works at all - that was already true.)

That is...

\documentclass[tikz,border=10pt,multi]{standalone}
\usepackage{forest}
\begin{document}
\forestset{%
  declare boolean register={line numbering},% line numbers
  line numbering,% default is for line numbers
  declare boolean register={justifications},% line justifications
  not justifications,% default is for no line justifications (b/c there's no point in enabling this if the user doesn't specify any content)
  define long step={proof tree proof first}{}{%
    if line numbering={%
      c2,descendants,fake=o,1,descendants,

Do I need

\begin{forest}
  [for nodewalk={before typesetting nodes processing order/.style={proof tree proof first}},
    [[[[][]][[][]]][[[][]]]]
    [[[[][]][[][]]][[[][]]]]
    [[[[][]][[][]]][[[][]]]]
  ]
\end{forest}

I tried for tree, for root... in place of for nodewalk... And why does this case need only one argument? I thought it needed two...

Or I can just put it in for tree with other things?

@SašoŽivanović Oh, wait. I can't say

if grouped={}{}

if `grouped is a boolean option? That only works for boolean registers?

@SašoŽivanović ^^ Not sure it is an improvement. Can't claim it is a form of modern art any more... ;).

@cfr for nodewalk does need two arguments. (I think this is the source of the misterious nodewalk stepped to the invalid node; stack: ",tree,back" error message.

It is correct (and intended) to put ... processing order/.style={...} within the for nodewalk

About too many nested delays. You can define your own stages. More precisely, you can invent your own keylist option (e.g. blabla) and modify stages so that it will include process keylist=blabla before typesetting nodes.

You can say if grouped also if grouped is an option. The following code works for me. (Did you forget the delay?)

\documentclass{article}
\usepackage{forest}
\begin{document}
\forestset{declare boolean={grouped}{0}}
\begin{forest}
  delay={for tree={if grouped={red}{blue}}}
  [A[B,grouped][C]]
\end{forest}
\end{document}

@SašoŽivanović  So how would you change the order in which, say, before drawing tree is processed for the tree? The manual gives

for nodewalk={before drawing tree processing order/.style={tree children first}}

as an example but that seems to have only one argument.

@SašoŽivanović I know. I wasn't sure how safe that was or whether any redefinition might go badly wrong with future Forest versions ;). And since I couldn't even figure out how to change the processing of current things....

@cfr That's a typo in the manual. I'll fix it.

@SašoŽivanović What should it say?

@SašoŽivanović So is

for nodewalk={processing order/.style={tree children first}}

also a typo?

for nodewalk={before drawing tree processing order/.style={tree children first}}{}

@SašoŽivanović Thank you! That makes more sense ... ;). Another question if I have not exhausted my lifetime allowance.... Can I make an autowrapped toks which I can treat like content? (Or a toks. I'm never sure which.) I tried

declare autowrapped toks={<option>}{}

but then I don't seem to be able to say

^^ Ignore the above. Did I mention I'm an idiot?

@SašoŽivanović Oh! You can't use false? It has to be 0?

Yeah ... the default value is not parsed by pgfmath ... that's a bit inconsistent, I admit. I can change this if you think it if you think it would be better.

@SašoŽivanović I think it would be better if it is not much trouble. If it is, I think a clear warning in the manual would be useful. What's especially confusing is that

declare boolean={<name>}{false}

often seems fine. It only causes issues if you then try to read it without setting it explicitly later. So you can have several such options and then add one and suddenly you get weird errors complaining that f isn't a number. And that's... well, it makes figuring it out rather challenging. Especially since, if you check the manual it gives possible values as

0 (false) 1 (true)

or something like that. And then goes onto explain that false/true are parsed as 0/1. So the use of false in your declaration doesn't exactly leap out as a suspect when trying to debug.

(I think this is responsible for several dead-ends I reached over the last 48 hours....)

@SašoŽivanović By the way:

Also, I found a way to eliminate the need for just to line which was a bit annoying. Now you can just say just=<stuff>, to line=<integer> and both wff and justification will* end up in the right places.

* 'will' in the sense of 'should', 'intended to', 'designed to' as opposed to 'predicted to', 'probably will' or 'guaranteed to'.

I had to add more delays. I never did get to use my node walk. It always gave me errors except when I used it in your enumtree thing where it worked fine.

I use forest, yay! Thank you!

Quack! :)

@Paolo You're the author of texdoc, right? Some people have reported that texdoc forest gives them the code (forest.pdf) instead of the manual (forest-doc.pdf), which is surely not what most people would want. I was suggested to rename the files. Would renaming the code to forest-code.pdf do the trick? (I'm not eager to part with my forest.dtx, but ah well...) Or is there something you can do?

Quack! ;-)