It's much easier to let the overload command do all the type-checking work rather than trying to do it in ModuleApply. Here is your module with my corrections. What I added is in green; what I removed is in orange.
 

Download Module_Test_Types.mw

The algorithm shown by @dharr is fairly well known; I remember reading it in a magazine (perhaps Games) as a child. The following property of that algorithm is much less well known. It doesn't help much when applying the algorithm by hand, but it allows for a big simplification in a computer implementation. It's this: The steps where one needs to go down instead of up and right due to a previously used position or going off the upper right corner happen iff the previously used value is a multiple of the order.

Also, for the verification procedure, I added a check that the elements are all different, which is usually considered part of the definition of a true magic square.
 

Download MagicSquare.mw

Like this:

ex:=
    G1*P3 + G1*P5 + G1*P6 + G2*P3 + G2*P6 + G3*P2 + G3*P5 + G4*P2 + G4*P3 + G4*P5 
    + G4*P6 + G5*P2 + G5*P3
    + G5*P5 + G5*P6 + G6*P3 + G6*P6 + G7*P2 + G7*P5 + G8*P2 + G8*P3 + G8*P5 + G8*P6
:
V:= indets(ex)[]:
codegen[optimize](unapply(ex, [V]), tryhard)(V);
    (G3 + G4 + G5 + G7 + G8)*P2 + (G1 + G3 + G4 + G5 + G7 + G8)*P5 + (P3 + P6)*(G1 + G2 + G4 + G5 + G6 + G8)

By the way, collect will also accept a list of variables: 

collect(ex, [P3,P6,P2,P5]);

It can be done with a one-line procedure:

Rose:= (n::integer)-> plots:-polarplot(sin(n*t), filled, color= `if`(n::odd, pink, aqua));

Test:

Rose(2);  Rose(3);

Given a planar graph G, the command

PD:= GraphTheory:-PlaneDual(G)

returns the graph PD whose vertices are the regions (a.k.a. "faces") of G and such that {u,v} is an edge of PD iff the corresponding faces of G share an edge. Unfortunately, this command doesn't give the face-to-vertex correspondence; however, it may be enough for your purposes.

The list of lists FL of vertices of G that define its faces can be obtained by 

GraphTheory:-IsPlanar(G, 'FL')

Vertices of degree 0, 1, or 2 in G can be a nuisance. I know this from long experience; I don't know whether they have any bad effect on these particular commands. Those vertices usually add nothing of interest mathematically to the study of planar graphs (or graphs embeddable on other surfaces), but they make many algorithms more complicated. I recommend that they be removed from G. Those of degree 0 or 1 can be removed outright. For a degree-2 vertex v, remove it and connect the two other vertices of its neighborhood if they aren't already connected. Continue recursively removing vertices of degree < 3 until there are no more.

@zenterix If I take your example worksheet, and add the line 

export getSeed, setSeed;

then it works, regardless of whether I use 1D or 2D. There are no hidden characters in this case. If your experience is different, then post a case with an error, not one without.

Here's a minimal implementation in 1D:

module NumberGenerator()
option object;
local defaultSeed:= 100, ModuleApply:= ()-> Object(thismodule);
export 
    setSeed:= proc(newSeed) local r:= defaultSeed; defaultSeed:= newSeed; r end proc,
    getSeed:= ()-> defaultSeed
;
end module
: 

I modified your setSeed to return the previous seed because I'm nearly certain that at some future point you'll wish that it was defined that way.

Background motivation: From the theory of limits of univariate functions (i.e., functions of a single real variable), recall the idea of directional or one-sided limits (i.e., limits from the left or from the right). Recall that if the left and right limits both exist but have different values, we'd say that the limit as a whole doesn't exist. We extend that idea to the multivariate case. There are now an infinite number of directions rather than just the two (left and right). If there are any two that give different limits, then we say that the multivariate limit doesn't exist (because it is path dependent, hence the title of this Answer).

Reduction of counterexample construction to the univariate case: Define the given function as f(x,y). For the sake of generality, I'll say that the limit point is (a,b) rather than (0,0). I'll define a path as a function y = g(x) such that limit(g(x), x= a) = b. (The notion of path in multivariate calculus is more general than that, but my definition is sufficient for the purpose of this problem.) If we can find two paths given by functions y = g1(x) and y = g2(x) such that limit(f(x, g1(x)), x= a) <> limit(f(x, g2(x)), x= a), then we'll have proved that the limit is path dependent and hence "doesn't exist" as a multivariate limit.

For the given problem, finding functions g1 and g2 that work is very easy, and there are many possible choices.

In Maple:

f:= (x,y)-> sin(x^2 - y^2)/(x^2 + y^2):
g1:= x-> ...:  
g2:= x-> ...:
#Check 1:
limit(g1(x), x= 0) = 0;
limit(g2(x), x= 0) = 0;
#Final check:
limit(f(x, g1(x)), x= 0) <> limit(f(x, g2(x)), x= 0);

I leave it up to you to guess and define suitable functions for g1 and g2.

Like this:

restart:
f:= t-> cos(3*t) + 2*sin(2*t-3):
T:= Vector(100, i-> 0.1*i):
data:= <T | f~(T)>;

You can combine an Interpolation object with a regular function in a numeric integrand as in this example:

P:= plot(sin(x), x= 0..Pi):
XY:= op([1,1], P):
f:= Interpolation:-SplineInterpolation(XY):
int(x-> f(x)/(1+x), 0..Pi, numeric);

If such an integral returns unevaluated, reduce the precision with the epsilon option:

int(x-> f(x)/(1+x), 0..Pi, epsilon= 5e-7, numeric);
 

There are a few other problems in your code, unrelated to the issue corrected by acer. The most prominent of these problems is this: Once a procedure executes a return statement, it stops executing. Thus, in places where you have two or more return statements in succession, only the first can possibly be executed. You can get around this by returning multiple values in a single return statement, for example 

return p, q, r

Here are corrections to your procedure:

conjcl:= proc(k::integer, p::prime, n::posint)
local q:= p^n-1, L:= Array(1..0), K:= 0, t;
    for t do K:= K+k mod q; L(t):= K; if K=0 then break fi od;
    [seq](L) 
end proc
:
conjcl(3,2,3);
                     [3, 6, 2, 5, 1, 4, 0]

Note that for your example values q = p^n - 1 = 7 is itself prime. That's a very rare occurence; there are only 51 known pairs (p,n) for which it happens. It's easy to prove that it can only happen for p = 2 and n prime. The upshot is that the returned list has all the integers 0..6 for any k not a multiple of 7, and thus the conjugacy class is the entire multiplicative group of the field. In general, that will only happen when k and q are relatively prime, i.e., when their greatest common divisor (GCD) is 1.

Here are the errors with your original procedure:

1. t needs to start at 1, not 0.
2. It's the multiples of k, not the powers of p, that matter; indeed p could never be a generator (a.k.a. primitive element) of the field GF(p^n).
3. Maple's mod doesn't distribute over <>.

This procedure is much simpler using syntax that is only available in 1D input:

conjcl:= (k::integer, p::prime, n::posint)->
local q:= p^n-1, K;
    [for K from k by k do K mod= q until K=0]
:

The need for an index variable in add and related looping statements can very often be avoided by using elementwise operations. I've typed the below in 1D, but they work in 2D also:

Omega:= (a::list)-> (-1)^add(a -~ 1);
Omega__rev:= (a::list)-> (-1)^add(a -~ [$nops(a)]);

There are many possible variations of the above, many of which avoid the internal creation of a temporary list. Here are two such possibilities for each:

Omega:= (a::list)-> (-1)^(add - nops)(a);
Omega:= curry(`^`, -1)@(add - nops);

Omega__rev:= (a::list)-> (-1)^(add - (n-> n*(n+1)/2)@nops)(a):
Omega__rev:= curry(`^`, -1)@(add - (n-> n*(n+1)/2)@nops):

I use curry and rcurry so often that I have the following predefined:

`&<`:= curry:  `&>`:= rcurry:

Using those, the above can be:

Omega:= `^`&<(-1) @ (add - nops):
Omega__rev:= `^`&<(-1) @ (add - binomial&>2 @ (nops+1)):
 

I think that you're misinterpreting the prettyprinted output of a permutation group object as a string. If you apply lprint to the output, you'll see that it's actually the PermutationGroup constructor. However, if you truly have a string such as you say, it can be converted to the group with this procedure:

StringToGroup:= proc(S::string)
uses ST= StringTools, GT= GroupTheory;
    (GT:-PermutationGroup@eval)(
        subsindets[flat](
            (`[]`~@{seq})(
                parse(ST:-SubstituteAll(ST:-SubstituteAll(S, ")(", ")*("), "(", "_("))
            ),
            `*`, op
        ),
        _= `[]`
    )
end proc
:
StringToGroup("<(1, 2), (1, 2, 3)(4, 5)>");
                <(1, 2), (1, 2, 3)(4, 5)>        

lprint(%);
GroupTheory:-PermutationGroup({Perm([[1, 2]]), Perm([[1, 2, 3], [4, 5]])},
degree = 5)

It should be 

cutoff:= eval(t, tempLrest[2])

The reason is that classical methods (almost by definition of classical) don't have dynamic error control such as variable step length. So, they are ignoring the errors that rkf45 is trying to prevent.

I don't know much about these ODEs with random input (are they stochastic DEs such as used in finance?), but perhaps ignoring the error controls is in fact useful.