I've changed your Post to a Question.

(This is the second time I've done that for your queries. Please submit Questions rather than Posts, for queries, thank you.)

@paulor Look at the Praw plot, which consists of all the roots of H(k,i) for each horizontal "k" value, ie. vertically appear the various "i" values of the roots.

The plottools:-transform command returns a procedure which may then be applied to a plot in order to transform it.

My plot tranformation applies your formula to all the (k,i) points, ie. roots. In my Answer, the parameter names x and y appearing in the construction of the plot-transforming procedure transf are arbitrary dummy names that I happened to pick. But perhaps it might be a little more clear to you if I had constructed it instead with these procedural parameter names,

transf := plottools:-transform((k, i) -> [k, ln((w(k) - i)*(A*alpha)^beta*(p(i)*i)^(alpha*beta))]):

For every point (k,i) on the curves in a plot, that transformer transf obtains the new horizontal component as simply k itself, and obtains the new vertical component by using the k and i values in your formula.

By restricting the vertical range of the implicitplot one can restrict the range of the roots found, which happens to also allow you to "separate" them for this example. I did that in my followup Comment.

Let us know if that doesn't make it clear.

The same very fast approach is easily adapted to get, say, only a few of the portions plotted separately. Eg,

str := time[real]();
P[1] := plots:-implicitplot(H(k, i), k = 1 .. 2, i = 6 .. 7, color = red);
P[2] := plots:-implicitplot(H(k, i), k = 1 .. 2, i = 7 .. 15, color = blue);

(time[real]() - str)*'seconds';

                 0.008 seconds

plots:-display(seq(transf(P[i]), i = 1 .. 2));

(For comparison, using vv's rootfinding technique took my machine 532 seconds to produce the separate plots of just the portions n=2..4, whereas the above implicitplot approach takes only a fraction of a second.

For fun, here's another coarse rootfinding jab at it, taking about 70 seconds. I used default adaptive plotting, so the memoization is not a big help. With some twiddles it could be sped up, but likely not nearly as fast as the implicit plot, so I didn't put in the effort. Worksheet_1_implicit_ac.mw)

@lcz Here's the %P format that I meant, for printf. I believe it was added in Maple 2019.

If you use fprintf then you could have it write out directly to file.

restart;
kernelopts(version);
   Maple 2021.1, X86 64 LINUX, May 19 2021, Build ID 1539851

printf("%P", eval(GraphTheory:-PlaneDual));
proc(G::{GRAPHLN, listlist})
    local F, E, i, f, k, j, n, e, S;
    if type(G, GRAPHLN) and not IsPlanar(G, 'F') then
        error "1st argument must be a planar graph or a list of faces o\
            f a planar graph.";
    elif type(G, 'listlist') then
        F := G;
    end if;
    n := nops(F);
    if n < 2 then
        return Graph(n);
    end if;
    E := table();
    for i to n do
        f := F[i];
        k := nops(f);
        for j to k - 1 do
            e := {f[j + 1], f[j]};
            if assigned(E[e]) then
                E[e] := E[e] union {i};
            else
                E[e] := {i};
            end if;
        end do;
        e := {f[1], f[k]};
        if assigned(E[e]) then
            E[e] := E[e] union {i};
        else
            E[e] := {i};
        end if;
    end do;
    S := {entries(E, 'nolist')};
    if map(nops, S) <> {2} then
        error "list of faces is inconsistent.";
    end if;
    Graph(nops(F), S);
end proc

As for showstat, there are situations in which revealing the line numbers is desirable, eg. using stopat.

@The function One of your images has the correct syntax. One does not.

It looks like the book's correct syntax was incorrectly transcribed.

You claimed that your input was the same. The two images shown have different inputs.

I can't tell whether the book's own bundled example .mw files don't match its actual text (their mistake),  or whether you incorrectly transcribed some example.

@Detlef Hoyer What I stated is true. I wrote that a number applied to an argument evaluates to that number.

In 2D Input the parser interpets your last example as multiplication. In 1D plaintext input it gets interpreted as function application.

My statement (to which you have objected) was not about what is typed or entered. My statement was about the parsed meaning. I made a statement about a number applied to an argument, not about a number positioned next to an opening bracket. You have mistakenly conflated the two, in your claim that what I wrote was not true.

What I wrote is also the central part of what went awry in your original Question's example, where adjacent bracketing was parsed as function application.

@GunnerMunk Your last comment's expectation is mistaken. You have the order of assignment back-to-front.

If you assign A:=3*a only after some assignment to `a`` then reassigning to `a` will not (by itself) update A.

If you assign A:=3*a prior to any assingment to `a` the you can get A updated automatically upon each new, subsequent assignment to `a`.

You've confused assigning three times "the current value of `a`" with assigning three times "a reference to `a`".

This behaviour is not directly related to this Question's original topic of re-execution flow of embedded context-menu actions on 2D Input.

@tomleslie That is a neat use of the nested seq for the indexing on the LHS of the prArr assignment statement, instead of a (uncompiled) nested loop. I suppose the inner seq can't be under a conditional because the entries aren't yet updated.

note: the only part of procedure Eratosthenes2 that was due to me was the single line,
   seq(`if`(L[n]=true,n,NULL), n=2..N);
as a replacement for the iterated list augmentation, because that was one inefficiency. The rest of that algorithm and choice of coding was due to the OP. I did revise the algorithm and do later modifications as procedures with other names, though.

@Ziaahmed812 

Last for me, fun as it was. This skips, dealing with the odd numbers only in the first stage. I didn't bother to reduce the Array size.

On my machine this does the N=2^20 case in 0.167 seconds, compared to the original which took 35.8 seconds.

restart;
Eratosthenes4 := module() local cstage1, stage1, ModuleApply;
  ModuleApply := proc(N::posint)
    local L, n, k;
    L := Array(1 .. N, 1, datatype=integer[4]);
    cstage1(N, L);
    2,seq(`if`(L[n]=1,n,NULL), n=3..N, 2);
  end proc;
  stage1 := proc(N, L::Array(datatype=integer[4]));
    local n, k;
    for n from 3 to trunc(sqrt(N)) by 2 do 
      if L[n] = 1 then 
        for k from n^2 to N by 2*n do 
          L[k] := 0;
        end do;
      end if; 
    end do;
    NULL; 
  end proc:
  cstage1 := Compiler:-Compile(stage1);
end module:

CodeTools:-Usage(Eratosthenes4(2^20)):
memory used=21.25MiB, alloc change=8.00MiB,
cpu time=167.00ms, real time=167.00ms, gc time=0ns

nops([%]);

                 82025

If you'd be willing to accept the results in an Array instead of a sequence (or list) then the second stage might be sped up too.

For fun,

restart;
Eratosthenes3 := module() local cstage1, stage1, ModuleApply;
  ModuleApply := proc(N::posint)
    local L, n, k;
    L := Array(1 .. N, 1, datatype=integer[4]);
    cstage1(N, L);
    seq(`if`(L[n]=1,n,NULL), n=2..N);
  end proc;
  stage1 := proc(N, L::Array(datatype=integer[4]));
    local n, k;
    for n from 2 to trunc(sqrt(N)) do 
      if L[n] = 1 then 
        for k from n^2 to N by n do 
          L[k] := 0;
        end do;
      end if; 
    end do;
    NULL; 
  end proc:
  cstage1 := Compiler:-Compile(stage1);
end module:

CodeTools:-Usage(Eratosthenes3(2^20)):
memory used=36.63MiB, alloc change=12.00MiB,
cpu time=319.00ms, real time=320.00ms, gc time=0ns

nops([%]);

                 82025

I have not implemented the refinement to work with only the odd numbers (and adjusting the increment accordinly).

The above is over 100 times faster than the (corrected) original posting, on my machine, for N=2^20. And it's slightly over twice as fast as the sieve routine that Tom's supplied in his Answer, on my machine, for N=2^20. But it is limited by the hardware integer size of N=2^32=4294967296.

@Ziaahmed812 For what it's worth, the following squeezes it a bit more (33% off the last timing above, for that size.):

restart;
Eratosthenes2a := proc(N::posint) 
local L, n, k; 
description "Calculate all primes less than or equal to N"; 
L := Array(2 .. N, i->true); 
for n from 2 to trunc(sqrt(N)) do 
  if L[n] = true then 
    for k from n^2 to N by n do 
      L[k] := false;
    end do;
  end if; 
end do; 
seq(`if`(L[n]=true,n,NULL), n=2..N);
end proc:

CodeTools:-Usage(Eratosthenes2a(2^20)):
memory used=132.76MiB, alloc change=20.00MiB,
cpu time=2.25s, real time=2.26s, gc time=988.78ms

nops([%]);

          82025

But I haven't looked at other accelerations.

@mmcdara I believe you would find that delaying evaluation (with uneval quotes, as you modified it) will not work in Malle 2021.1 for this example involving units. I had discussed this in my own Answer.

@Anthrazit I prefer to have a procedure do multiple-returns (ie, return an expression sequence), along with multiple-assignment. Eg,

  (A,B,C) := F(...);

with F here returning an expression sequence of three things.

That's for assignment/side-effects. For merely accessing globals I prefer using the colon-minus syntax for make references to a global variable, eg :-A to get at global A.

@GunnerMunk If I place the mouse-pointer on the output of the context-menu result (here, the result 9*Unit(m^2) from the inserted, inlined simplify call) and then make the keystrokes Ctrl= (`Ctrl` and `=` together) then that result of simplifying a*b gets updated with the new values for a and b.

In my Maple 2020.2 the consequence of pressing only the Enter key when the focus has progressed to the a*b 2D Input line is that I get a new, additional 2D Output (with updated values) , but the previous inlined context-menu result remains and is bumped down, as some kind of undesirable output artifact. That doesn't seem desirable, to me.

I don't use Document mode because I find the execution flow awkward, especially wrt to automatic advancing of the cursor when trying to use Enter or Tab, or lack thereof. I'm not telling you it's all ok. I'm simply informing you of ways that I was able to update the prior context-menu inlined output.

Your problems seem quite unspecific to units or the simplify command itself.

Your issues appears actually to be related to the execution flow that attains when on uses context-panel actions on 2D Input in a Document.

I do not know the "best" way to re-execute an inserted context-panel action (made on 2D Input, in a Document). But if I hit the menubar's !!! (triple exclamation button) then I can get all lines to re-execute sucessfully.

You did not attach your Document, which is not so helpful. I have guessed that it is like this:
  CM_Document.mw

note: I personally find Document mode's execution flow model to be unreliable and confusing, and only use Worksheet and 1D plaintext mode for input.