@cfr Yeah. In moving my ass! ;-)

@cfr Ok, I've redefined filter. It now works with sort. I've tested it in my .sty:

  create line numbers and justifications/.style={
    % sort the nodes top-to-bottom, left-to-right
    % the plan is to walk this sorted nodewalk and increase the line number when y changes
    sort by={y,-x()}, for sort'={filter={tree}{!strequal(content(),"dont")}}{
      % create the first line number & justification manually
      % (nodewalk step !back doesn't work on the first node)
      tempcounta'=1,
      new line number/.process args={RO}{tempcounta}{y},
      new justification/.process args={ROO}{tempcounta}{just}{y},

Your code from above should be modified to read like this:

... but I haven't tested this, obviously. Hope it works.

@cfr I'm sending you the new forest.sty over email.

@cfr I see two ways of doing this.

(i) I've already got undef option (I needed for some compat key). I could split off a part of it into make option readonly. This way, you could set the option value in the usual way, but then prevent further changes by making it readonly.

(ii) Declaring the option readonly (declare readonly dimen and declare readonly count actually already exist, for n, level etc.) and using a special key set@option, clearly marked as "developer", to set its value.

@cfr Not only was filter badly designed, the same issue is with branch (and c-commanded that uses it). Redesign goes to my todo list ...

@SašoŽivanović This would be helpful. For now, I've buried it by using a prefix I'm saying marks internal non-user commands. But it would be nice to allow users to read it. (i) wouldn't help in this case as I probably might need to change it. I don't want to make it so read only I can't change it. I just don't want to expose it to inadvertent changes.

@SašoŽivanović What I've currently got is actually working pretty well right now. I guess the filter would be faster, probably? I did try creating the line numbers as I counted the levels, but the problem is that stuff I'm doing later depends on each line number being the child of the previous one. (Because the way I'm getting things moved gets y wrong initially and corrects it later after the line numbers and justifications are created. I couldn't make your way work without your results.)

@cfr (ii) it is then.

@cfr filter would surely be faster, yes, main reason being less nodes to sort.