@Carl Love 
No, the modules are just fine. As I said, it was pure curiosity, but I don't use them very often (except packages) and I was trying to understand if in such situations they are really more efficient.
Using modules the debugging could be more difficult if something goes wrong.

Edit. You say: "the syntax of the inner procedure is checked when it's originally entered. But the assignment := is not done".
AFAIK, when defined, the body of the procedure is translated into internal code (that is what I understand by parse here). So, why should the inner procedure be "re-parsed"?
 

@Carl Love 

But in the procedure version of MakeTreeTable, when MakeTreeTable is defined (parsed), this implies (in my opinion) that all its body is parsed, including MakeTable.
Probably in other circumstances the use of modules is preferable.

@Carl Love 

Just curious: is there any benefit in using modules e.g. in MakeTreeTable versus the equivalent procedure?

MakeTreeTable:= proc(depth::nonnegint, width::nonnegint)
local
   i, node:=0,
   nextnode:= proc() node:= node+1 end proc,      
   MakeTable:= proc(depth :: nonnegint, width :: nonnegint)
      if depth = 0 then nextnode()
      else table([seq(nextnode()=thisproc(depth-1,width), i=1..width)]);
      end if
   end proc;
MakeTable(depth, width)
end proc;

@asa12 
Let us try to formulate mathematically the problem (if I understand it correctly).

You have a function space  FS, for example C^infinity(J)  (= the algebra of infinitely differentiable functions on the open interval J) . You also have an operator A defined (partially) on FS, in your case it is:

   A(a) = a' / (a * a' - a).

You want to find another operator f defined on FS such that

   f( A(a) + A(b) )  = f(A(a)) * f(A(b)),  for each a,b in FS.

Such an f is for example f = exp, or more generally, f(a) = exp(s*a),  s being a scalar.

Now you want an operator f, similar to diff. I suppose that this means:

  f( A(a) * A(b) ) = f(A(a))*A(b) + A(a)*f(A(b)).      [*]

(I suppose you want to exclude the trivial case f=0).

Maple probably cannot do this. And I am not sure if such an operator - other than f = D - exists. It may depend on FS, which you should know, because it is your ploblem. And I am not sure if [*] is what you want.

@asa12 

Maybe you want an Infinitesimal generator, see https://en.wikipedia.org/wiki/C0-semigroup#Infinitesimal_generator
But you must learn no ask the question in proper terms (preferably using some maths and without non-working Maple code), otherwise it is "quasi-impossible" to be understood.
 

@Carl Love 

Nice solution, vote up.
Don't you thing that using multi-indices is more efficient?
I wonder why the OP has no reaction.

@Kitonum 

It's OK but you should add the step about the equivalence, for those thinking that it is not obvious.

[ 2y=x(1-y^2)  <==> 2y/(1-y^2) = x,  because y cannot be +-1]

P.S. In my opinion, using Maple without knowing maths is not recommended.

@Markiyan Hirnyk 

Of course you do, it's not something new.

@Markiyan Hirnyk 

They include the cases when both sides are undefined (but actually solutions in the Riemann sphere).
If you want to exclude this cases, simply take integer _Z
with  - _Z <> W + 2*W^2,  for integer W.

@one man 

For a cone the geodesic distance is straightforward, so the exact parametric equation of the spiral is obvious.

@Carl Love 

Looking at showstat(`mod/Factors`)  we can see that a table s is created and then
factors := convert(s,'multiset');
As shown in my answer (and reply), this will (could) produce a random order.

To test this, I'd suggest to modify `convert/multiset` inserting indexorder and see whether the random behavior persists.

By coloring the cube with color f(x,y,z) you will have information on f only on the boundary of the cube.
That is, only f(0,y,z), f(1,y,z),...,f(x,y,1) are visualized.
You can't "see" e,g. the value f(0.5, 0.6, 0.7).
So, you will see the max/min only if they are on the boundary.

@Carl Love 

Sorry for the confusion, but I thought that the reference to Eigenvectors is obvious because of the presence of lambda.

@Carl Love 

Eigenvectors produces a random order for the eigenvalues because after solving the characteristic equation with the local variable lambda, indices is called.
You are right about indexorder. The procedure which calls indices without indexorder is `convert/multiset`. If we change it inserting indexorder, the random behavior disappears.

@Markiyan Hirnyk 

OK, it's enough for me too.
P.S. I wish you good luck in obtaining small Groebner bases using the cited articles.