I assume this occurs because the procedures in the list passed to overload are not exports of the module.  You could work-around this by assigning them as exports and then calling them from the overloaded procedure.  For example

export foo1 :: static := proc(_self, k :: integer) ... end proc:
export foo2 :: static := proc(_self, k :: rational) ... end proc:
export foo :: static := overload([
  proc(_self, k::integer) option overload; foo1(_passed); end proc,
  proc(_self, k::rational) foo2(_passed); end proc ]):
                                           

Not ideal but it should work. 

Later It makes more sense to declare foo1 and foo2 as locals, since presumably they wouldn't be directly accessed.  That also works.

I consider this a bug and have previously reported it as such.  The use of _self as a formal parameter in an object method allows object locals to be accessed without prepending the _self:-, however, this only works if the formal parameter _self is declared with no type.  If you remove the type declaration in ModuleCopy, then you can access the name local directly.

Rather than just give you the solution, here's the basic idea.

J := proc(n :: posint)
    if n = 1 then 1
    elif n :: 'even' then
         # some expression calling J
    else
         # some other expression calling J
   end if;
end proc:

# to check the result, do
[seq(J(n), n = 1..16)];

There is some weirdness with the 2D input for the plot command.  I exported the worksheet as Maple commands:
 

restart: i := I:
with(LinearAlgebra): 
E := 100;
Z(R) := (5+5*i)*(R-10*i)/`+`(5+5*i,R-10*i);
I__R(R) := E/Z(R);
F(R) := abs(I__R(R)); _maple_label_L51 := '%';
# "plot(F(R),R=0..100)->"
plot(_maple_label_L51);

Clearly there is a problem with the plot statement.  Reentering it manually fixes the issue.

As an aside, it's probably better not to assign functions using the syntax foo(x) := whatever; that only works in 2D mode. The "standard" way is to do foo := x -> whatever. 

By Geometric Algebra I assume (didn't open the link) you mean David Hestenes' take on Clifford Algebra.  There is a Maple package for Clifford Algebra, named Clifford I believe, by Rafal Ablamowicz.  I haven't looked at it in a long while.  At that time I wrote a package, named Glyph, for doing Clifford Algebra in Maple, but it is much out of date.  Ian McCreath revised it a few years ago, for his own purposes, mainly for study, I think.  I could ask him to contact you.  Writing a Maple package for this is a a great way to learn.

As tomleslie suggested, posting an example would be helpful.  Piecewise expressions that don't depend on solving variables (currents and voltages) should already be doable; if not, I'll extend Syrup. Piecewise expressions that depend on solving variables would be really useful, but its unlikely I'll implement them.

White-space is not needed after the closing parenthesis in the formal parameter sequence of a procedure statement.  For example

proc(x)x^2;end(z);
                                         z^2

There are places where white-space is required, say after a for.

Later Actually, you technically don't need white-space even after a for, and possibly not anywhere, though the alternative is rather ugly.  I'll leave that as a puzzle for now.

For strings you can also use seq, at least with newer versions of Maple.  Maybe not Maple 18.

seq("abc");
                  "a", "b", "c"

There are a few problems with the circuit.

A full bridge rectifier should not be grounded on both sides.  Float the source (the sinewave current source).  Connect the return path of the bridge to the current source (in the model it is unconnected).

The impedance of the load (C1 and R2) is too low.  The peak source current is 45uA, you cannot drive a 1ohm resistor and see more than 45uV.  Increase it to something much higher, say 1Mohm.  C1 should be much smaller, maybe 1nF.

At 40Hz (the frequency of the sine wave), the impedance of the 171nF cap is 23e3, which limits the peak voltage to about 1V.  I'm not familar with piezoelectric devices, so have no idea whether the model is reasonable, but to get a significant voltage out of it in that configuration the capacitance has to be much smaller.

Make all the diodes the same; you can do this by selecting all of them and using the common parameter tool.  Currently they have a mix of values.  Set Vknee to 0.7 and Goff to 0.

A useful way to debug this, and other circuits, is to test in pieces. With MapleSim this is fairly easy. For example, you can disable everything to the right of the piezoelectric model (select the parts and click the enable/disable icon on the toolbar), add a temporary ground, then check whether the voltage across the piezoelectric device produced is reasonable.

Just a heads up; I'll be uploading an extension to Syrup sometime soon---probably within a week or two.  Nothing big, but it will allow diodes, subcircuits, and probably op-amps in ladder notation.  Will post to MaplePrimes when its ready.

It's not clear to me what you are attempting to do, but the implementation isn't going to work.  Here's why.

The voltage at the non-inverting input of the lower op-amp (probe1) is 0.3V.  For the op-amp to be in the linear region, the inverting input (probe 2) should be at that same voltage (0.3V).

The voltage at the non-inverting input of the upper op-amp is 0.5V. So the voltage at the inverting input should be 0.5V. So the highest voltage attainable at probe 2 (assuming mosfet had zero resistance) is  0.5V*R4/(R4+R5) = 0.5V/11 < 0.05V < 0.3V.  There is no chance that the lower op-amp is in the linear region. 

Thomas Richard's answer is the right one.  Another point; that design isn't going to work (I haven't actually tried to simulate it); there is a problem when switch1 is open as the constant current source has nowhere to go.  A crude solution would be to add a diode clamp to a voltage source greater than the fully charged battery.  Better would be to use a signal current source, turning it on to charge and off when the battery is sufficiently charged. 

The error message is giving you a useful hint.  Change to a stiff solver:  click the "wrench" on the right vertical toolbar and select "Rosenbrock" from the Solver menu.

There are two other relevant issues.  First, the output resistor (R3) has its default value, 1ohm, which is rather low for a typical op-amp. Pick a more reasonable value, say at least 1K.  Second, the op-amp needs a negative rail; in the given model the negative rail input (m) is grounded.  Connect it to, say, -10V.  That will allow the circuit to work properly during the blocking phase.

As C_R suggests, you can use the ideal opamp here.  If you don't care about the op-amp characteristics (say effects of limited bandwidth, output impedance, etc) that is frequently the way to go if it works, however, it won't work in all circuits.  The ideal op-amp merely enforces a virtual ground between its two inputs; it won't work in a switching circuit (say as a comparator).

The circuit is missing a positive bias for the drain of MNMOS2 so that circuit would never perform properly. Also, the two NMOS devices are missing model card parameters.  Alas, fixing those issues won't help here; the mos devices from the SPICE3 library don't work particularly well in MapleSim.  You can model this using the standard mos devices, see current_mirror2.msim, in which I added slightly mismatched resistors and a supply with a ripple voltage so that you can see some mismatch in the currents.

Use unapply.

b := unapply(a(x)+x^2, x);

An alternative approach is just use expressions:

a := x + 1:
b := a + x^2:
a := x + 5:

To evaluate, say, b at x = 3 you could do

eval(b, x=3);