There are two issues.

Your original call to plot3d suffers from premature evaluation. One way to deal with that is by using additional unevaluation quotes (as Carl and Kitonum showed). I find that approach slightly awkward and slightly confusing since, as you say, you don't understand just how it works.

Another way to deal with that evaluation issue for the plot3d call is to use operator form for its arguments. I show that in the attachment below. This also deals with the ugly and awkward need to keep unassigning epsilon,m,n, etc.

But you also asked about why the 2D plots differ between Maple 2017 and Maple 2019. In Maple 2019 the call to fsolve inside your qN_ep can return a value at which its expression is very close to zero (yet the expression's slope is also near zero). I suspect that what you want instead is the earlier root that passes through zero without small slope. See the attachment.

The plot3d call takes a while because you have Digits=100. I'm not sure that you need to set it so very high. Try it at 20.

plot3d_test_ac1.mw

In addition to what Kitonum has already mentioned, you might find the following of interest.

Download surd.mw

The typesetting level matters here.

Download inert_div.mw

The very first request's target (expected result) has the c4 factored out but not nurdel. That is not consistent with the later examples' expected results.

I am not seeing a consistent definition of how the OP expects the input expressions to be handled, so I don't see a common approach. Have I missed a consistent definition of the treatment?

Download collect_examples.mw

The use of unapply on an applied function call (involving name x, or a picked-off parameter name) -- where the application serves no other purpose -- is madness. If the particular names of the procedure's parameters matter, then the approach seems wrong.

Your examples may well not illustrate precisely all or what you're trying to achieve.

But this may cover some of it. Note that the foldl example illustrates calling the iterating procedure, not constructing it. 

restart;

Q := sin@@3;
                  Q := @@(sin, 3)

Q(0.25);
                   0.2424474664

K:=proc(F,X,L2,n)
     foldl(L->F(L,op(_rest)),X,L2$n);
end proc:

for k from 0 to 3 do
    K(f, a, [b,c], k);
end do;
                        a
                    f(a, b, c)
               f(f(a, b, c), b, c)
           f(f(f(a, b, c), b, c), b, c)

Do you have other, more involved examples that you haven't shown us yet, which have additional demands?

My concerns are not just that I think that the names of the parameters of a procedure ought to act like dummy names (ie. the particular name choice should largely not matter). You should also be careful that a methodology which extracts the parameter names doesn't break just because, say, the global names have already been assigned values. (I mean where the construction breaks because some procedure's parameter names like x have been assigned.)

Look at the Help for the randomize command.

Compare what happens when you run these several times:

restart;
f:=rand(1..100):
seq(f(),i=1..10);

restart;
randomize():
f:=rand(1..100):
seq(f(),i=1..10);

The randomize command has a similar effect on Random Number Generators (RNGs) in the Statistics and RandomTools packages.

You don't need to implement your own RNGs simply to get different random sequences from different sessions.

Here are two ways, using your original assignments to SOLNSuy.

Download usman_anim.mw

It's not a big deal, but you could also use trunc rather than floor in the first approach above. However I find the second approach -- using seq -- more natural. (A pun for the year's end.)

Are you looking for one of these?

plot(x-floor(x/3)*3, x=-5..5);

plot(fmod(x,3), x=-5..5);

(Note that they are not the same.)

That Example unfortunately shows only how to have text use the current Style that is set for Hyperlinks, rather than an actual hyperlink.

There is a Hyperlink constructor exported from DocumentTools:-Layout, but it is not documented. It's also not a package export, so its name is not rebound by with. But it can still be called by its full name.

with(DocumentTools):
with(DocumentTools:-Layout):
F := Font("Official NORAD Santa Tracker", size=12, color=blue, style=:-Hyperlink):
H := DocumentTools:-Layout:-Hyperlink(F,linktarget="https://www.noradsanta.org/"):
InsertContent(Worksheet(Group(Input(Textfield("Track Santa at the ",H))))):

It is not a bug. But it is a commonly asked question.

for i from 1 to n do a[i] := unapply( b[i](u), u); od;

I consider it safe to assume that you've given us a toy example merely for the purpose of illustration, and that your actual examples are more involved. Otherwise you could assign more directly from b to a, or b[i] to a[i]. I assume that you are not working with this trivial task.

If you have a more involved example for which the above approach does not work as you want then show us the full example. There are too many variants to guess thoroughly.

Eg, you might want the i in  b[i] to be resolved in the body of the new operator/procedure -- while neither b[i] nor the call b[i](u) are yet resolved explicitly or executed. That could be done as follows, which also handles even more complicated cases,

for i from 1 to 2 do
   a[i] := subs(__dummy=b[i],(u->__dummy(u)));
end do;

Such subtleties might not matter to your workflow. It could conveniently allow you to change any or all of the definitions of the b[i] without having to reassign the a[i]. That might well not matter to you.
 

Substitute for 1-gamma first, using e_nsp2. Then you can substitute for gamma using e_nsp1 (without interfering with the original 1-gamma terms).

(You could also separately freeze the relevant terms 1-gamma and gamma, and then do the substitutions together. But your example seems unambiguous and so this may not be necessary here.)

Download question_1_ac.mw

You are missing a comma between the 3rd and 4th equation in the definition of Inter.

Also, did you realize that Inter contains lambda[1], etc, while the eqs and Sol contain lambda__1, etc? I'm not sure which you want, but I've changed them to match, here. tes_ac.mw

I suspect that the real lesson to learn here is: Do not evalf non-constant expressions before it is necesary! Doing so can easily result in loss of accuracy when doing subsequent numeric computations, due to roundoff error in the approximated coefficients.

Leave coefficients as exact values as late as you can. It may prevent roundoff error from hiding roots, or finding true extrema, and it might even allow useful symbolic simplification.

In this example it looks as if the supplied expression contains a mix of exact names (ie, x) and floating-point coefficients. It seems possible that some (earlier) representation or characterization might be possible in which a wealth of multiple roots could be ascertained.

Below I use Maple 2019.1.

Download solve_equation_ac.mw

Calling fsolve with a maxsols option (alas, undocumented) is just a hook to NextZero. It's an alternative to Student:-Calculus1:-Roots(...,numeric) which calls fsolve recursively.

Also, we can note that a 10-digits approximation to an actual root can possibly produce a large residual (forward error). That can happen simply due to the fact that the root (or the coefficients) have been already rounded. 

In Maple 2015 you'll need to account for the special-evaluation rules which Explore has on its first procedural parameter (ugh).

Here is one way that seems to handle your posted example, in a procedure. I used Maple 2015.2. Here I deliberately stuck to your original approach.
Explore_Procedure_ac1.mw

ps. I mean no offence, but I have reservations about this whole approach, including picking apart RVs. (I don't understand what great convenience that brings over passing around a distribution name and parameter names, at the risk of complicated and IMO hazy mechanisms.) And to go to such efforts, while global :-x must still be unassigned, etc, seems awkward to me. Perhaps I don't properly understand how this OBSERVE procedure is intended for use.

The command with is not intended to work inside a procedure body. It's Help pages documents that clearly, with examples. That is the primary cause of the error.

I have changed your definition of PR to utilizes the uses syntax instead.

does_not_evaluate_ac.mw

Since you're using Maple 2019 you might find its new Calendar package easier for those computations (eg. date differences).