Here are some Answers to your Q2 and Q3. You asked:

• Q2:-  What is a good way to handle different numbers of inputs to procedures (exported) here eg Proc1(a), Proc2(a,b), ....,                   ProcN(a1,...,aN)

Hmm, I don't see those procedures, nor does the given module have any exports. Perhaps this module is intended to be part of a larger module that you didn't post? Anyway, notice the change that I made to your two-parameter procedure in the overload. I changed its header from proc(A, B) to proc(A::_T2L, B::_T3L, $). That $ means that overload will reject that procedure and move onto the next one if the number of passed arguments is more than 2. If you use $, it must be at the end of the parameters.

• Q3:-    Would the package exports of the module be the procedures inside the Mydispatch? Or does all of MyModule sit inside the  package module?

MyModule does not have any exports; its only interaction with the outside world is through its ModuleApply. At the moment (not seeing the overall package), I see no reason to put the code of MyModule inside another module. But you can call it from any other module, or, indeed, from anywhere at all.

Since the final polynomial obtained by @acer compares favorably under various metrics to the one produced by you by hand, produced by me by hand, and produced by codegen:-optimize(..., tryhard) (which are all the same polynomial except for slight differences in the order that the variables appear), one may wonder why optimize didn't return it. There are various metrics in use in this thread. I'd guess that the two primary ones actually used for optimization (rather than just being measured for curiosity) are 

• Length: essentially order isomorphic to the number of characters in a displayed form of the polynomial. Good and essentially order-isomorphic approximations to this can be obtained by the commands length (built-in and extremely fast) and `simplify/size/size`, used by the important optimizing command simplify(..., size). The exact number of characters is returned by (length@String), which could also be used as a metric, but isn't used by any of the methods discussed so far in this thread. 
   
• Operation count (which I'll abbreviate as opcount): A count of the number of basic computational operations (mostly arithmetic and assignment) that are needed to evaluate the expression to a (one-word) number when the variables are given (one-word) numeric values. This is the metric more closely related to computational efficiency and the one used by codegen:-optimize(..., tryhard). It allows for the use of intermediary variables (used for repeated subexpressions). This metric can be obtained (exactly) by codegen:-cost.

You may have noticed from my Answer that I used these steps:

1. Extract the variables from the expression ex by using indets;
2. Convert ex to a procedure by using unapply;
3. Put that procedure through optimize, which returns a new-and-improved procedure;
4. Apply that new procedure to the original symbolic (i.e., non-numeric) variables.

I used step 4 in case you were truly interested in the displayed length of the expression; however, for those interested in computational efficiency (as measured by opcount), step 4 is a very bad idea. Here is (essentially) the optimized procedure returned by optimize. Since it uses meaningless names for the intermediary variables, I changed them to meaningful ones; and I used modern sleek syntax (which requires 1D input):

new_ex:= (G1, G2, G3, G4, G5, G6, G7, G8, P2, P3, P5, P6)->
local G458:= G4 + G5 + G8,  G34578:= G3 + G458 + G7;
    G34578*P2 + (G1 + G34578)*P5 + (P3 + P6)*(G1 + G2 + G458 + G6)
:

You can easily obtain the opcount by eye---11 additions, 2 multiplications, 2 assignments, 2 (local) storage---which is also what codegen:-cost(new_ex) will say. This is significantly better than if step 4 is used, that result having 17 additions and 3 multiplications.

@666 jvbasha A negative number raised to a fractional or "decimal" power is always nonreal. I don't know if the derivative that you raise to the power n-1 is ever negative, but if it is, there will be a problem. I doubt that Maple's numeric PDE solver could be made to work with nonreal values.  

@Kitonum Sorry, I meant to say that it needed to be changed for n=2.

@Kitonum Given that r = sin(n*theta) is specifically used in the Question's title, I did not intend for the parameter n to represent the number of petals, only for it to have the same parity as the number of petals. Your procedure needs to be changed for n=1.

I immediately see several things that can likely be made more efficient. But before I go too far with that, please supply some suitable arguments to call the procedure so that I can test my ideas. In other words, for the call 

mcmcBinomialBeta(a, b, n, k, init, N, burn, thin)

what should I use for the values of a, b, n, k, init, N, burn, and thin? 

Also, will "hardware floats" a.k.a. "double precision" (64-bit floats) be sufficiently high precision for you?

@smithss Your previous Question was about a Maple program that you wrote that defines an external process to read a specific email you may have received (or report that it hasn't received). I think that that would be more easily done with the ssystem command shown by @nm. For example, I've used it within Maple programs so that they would email me debugging-related information about the program execution. 

@ecterrab Okay, Edgardo, after discussing with the OP (shown below), I think that there is an issue. It might not be formally called a bug, but it's a serious issue. So I encourage you to file that report. The anomaly is fully described by the first and last paragraphs of help page ?local_scopes. But, see, that was Maple 2019, and it hasn't been fixed yet. There are a huge number of these 1D - 2D divergences due to syntax enhancements, going back to Maple 2017 (and maybe earlier). They're all duly noted on their respective help pages (usually at the bottom), but then seemingly forgotten by the GUI developers. 

@bstuan The path need not be a straight line. I just woke up, so I haven't tested these yet, but my first guess is g1 = 0 and g2 = x-> x^(2/3) with the limits being 0 and 1/2. Let me know how it goes.

@zenterix Yes, it works in 1D due to a recent syntax enhancement. (Code edit regions are 1D input.) It's an example of what I meant by "that distinction has been fading over the years." When I said "Your error is that you have an export declaration after the above statement," I meant that that's your error if you're using 2D Input, which seemed to be the intent of your Question. 

Nearly every (perhaps absolutely every) syntax enhancement made to 1D input in the last 4 years does not work in 2D Input. And there have been a huge number of such enhancements.

These are the first paragraph and the last paragraph of help page ?local_scopes:

• Maple 2019 removes the requirement that all procedure and module local and global variables, and module exported variables, be declared at the beginning of the procedure or module before any executable statement.
• This feature is currently not supported in 2-D math input in the Standard Interface. It is supported in 1-D math input in the Standard interface, as well as in the Command-line user interface.

@bstuan You wrote:

• I thought that the limits of g1(x) and g2(x) must always be = 0(?)

Yes, we must have limit(g1(x), x= 0) = 0, and likewise for g2; but limit(f(x, g1(x)), x= 0) can be anything.

The simplest possible g is 

g1:= x-> 0:

Visualized geometrically, this is approaching the origin along the y-axis. Using that, what do you get for the limit?

@zenterix There is a distinction that must be made between declarations and statements, although that distinction has been fading over the years. In a module, the declarations must come before the statements. All of these are declarations:

local defaultSeed;
local defaultSeed:= 100;
export getSeed;
export getSeed:= ()-> defaultSeed;

But this is a statement:

defaultSeed:= 100;

Your error is that you have an export declaration after the above statement.

By combining the declaration of the names and the assignment of their (initial) values, it's possible to write useful modules that are all declarations, no statements. The majority of modules that I write are like that, as is the example that I gave.

For reasons that I don't understand, I seem to be the only one who does it this way. One benefit is that you don't need to retype (and possibly misspell) the variable name.

The reserved words local and export only need to be used once, each followed by a comma-separated sequence of variables with their initial values (exactly like the example I showed). I always do it that way. Sure, you can put local or export in front of every variable, but why would I type any word more than once if I don't need to?

You wrote:

• One thing you might note is that I am literally trying to learn about Maple from the official documentation. I simply use what is there. Initially I was reading Chapter 8 about Modules of the Programming Guide....

Likewise, my entire knowledge of Maple comes from reading the official documentation (including the Programming Guide), this forum, the fora that existed before this, and experimentation. I haven't learned from any teachers or books about it. I've looked through many third-party books with Maple in the title, and I have many on my shelves. While most of these books do do a decent job of teaching whatever type of math they're trying to teach, their Maple content is appalling. The only exception that I've seen is Calculus the Maple Way by Robert B. Israel, who used to be a frequent contributor here.

@bstuan I'm trying to not give away too much of the solution here, but if I choose the simplest possible examples for g1 and g2, then I get a limit of 0 for one of them, and 1 for the other.

And note that you should be calculating the limit of f(x, g1(x)), etc., rather than f(g1(x)) (which you've typed above).

@ecterrab You wrote:

• I am forwarding the problem you posted to the people who take care of that, adding it to the database of issues too.

At this point, I don't see any "issue". Perhaps you should wait for clarification from the OP before forwarding. I've already asked for that clarification.

@acer An even better plot can be made by specifying adaptive=true (or, equivalently, simply
adaptive)^[*1] and "anchoring" the zeros with sample:

plot(abs(sin(x)/x), x= -2*Pi..10*Pi, sample= Pi*~[$-2..10], adaptive);

[*1] A curiosity: Using a keyword option as an argument without specifying a value is equivalent to setting the keyword to true, regardless of the declared type or default value of the keyword. Example:
P:= proc({opt::anything:= ()}) opt end proc:
P(opt);
                              true
One may debate the robustness of making use of this feature.