This is a well known bug of the Standard GUI. See here and linked threads.

Trace what is doing by adding these lines:

trace(`evalc/evalc`):
trace(`evalc/power`):

before FT := FourierSeries(ByFin.... You will see that the proceedures `evalc/evalc` and `evalc/power` keep calling each other, until they cannot do it any longer, as here:

{--> enter evalc/evalc, args = 0.^(25.5297102965911300/(1+1.*exp(33.802045-9.27\
285581833315754*parDist(x*cos(1/12*Pi)+t*sin(1/12*Pi),-x*sin(1/12*Pi)+t*cos(1/
12*Pi))+.958468144384899466*parDist(x*cos(1/12*Pi)+t*sin(1/12*Pi),-x*sin(1/12*
Pi)+t*cos(1/12*Pi))^2))+2.2084788+0.*I)

Clearly, the problem is with this expression that they get as argument, more specifically with the parDist function call, as it seems like they cannot do anything with it.

I would not be so drastic. If using Maple 17, a local I can be used, see ?updates,Maple17,EasyOfUse#localnames .

Read ?ProgrammingGuide,Chapter10 . See also, e.g. this thread.

Indeed, this is the fix point design bug for applyrule, that I have described here, together with an alternative procedure applyrule1 that makes the transformation a controlable number of times, one by default.

Now the reason why the first rule does not enter into an unending loop is another design bug of the PatternMatching package, namely that only a handful of procedures are implemented to be used in the rules. It can be seen when generating the "compiled" form of the rule:

> r1:=[c1::algebraic * exp(c2::algebraic)=(  c1 * exp(collect(c2, v_collect)))]:

> compiletable(r1);
/ODER([/KOMUTA(/POS(1, *), /ODER([
    /BIND(1, /c11::algebraic), [/POS(1, exp, 1), /BIND(1, 1, /c12::algebraic)]]
    , [
    [/POS(1, exp, 1), /BIND(1, 1, /c12::algebraic)], /BIND(1, /c11::algebraic)]))
    , /PATTERN(/c11 exp(/c12))],
    [/POS(1, exp, 1), /BIND(1, 1, /c12::algebraic), /PATTERN(exp(/c12))])

The relevant parts to look at are the /PATTERN function calls: they have the form c1*exp(c2) or exp(c2) for the special case of c1=1 (as the type being used is algebraic, which includes the multiplicative unit). In other words the procedure collect  is directly replaced by the identity. Hence, the transformation gets the fix point at the first iteration by doing "nothing".

On the other hand, no such problem occurs with names, in particular inertized function names like %exp:

> r2:=[c1::algebraic*exp(c2::algebraic)= c1*%exp(%collect(c2, v_collect))]:
> compiletable(r2);
/ODER([/KOMUTA(/POS(1, *), /ODER([
    /BIND(1, /c11::algebraic), [/POS(1, exp, 1), /BIND(1, 1, /c12::algebraic)]]
    , [
    [/POS(1, exp, 1), /BIND(1, 1, /c12::algebraic)], /BIND(1, /c11::algebraic)]))
    , /PATTERN(/c11 %exp(%collect(/c12, v_collect)))], [/POS(1, exp, 1),
    /BIND(1, 1, /c12::algebraic), /PATTERN(%exp(%collect(/c12, v_collect)))])

So, where do we stand on the subject of transformation rules? There are many facilities in Maple like subs, eval, algsubs, evalindets, subsindets, applyrule, etc.  None is a universal tool, and each one has its strong and weak points, which are different, so that it all depends on the specific application. And sometimes a combination of evalindets with applyrule, say, is even more powerful.   

I think that the easiest way of implementing this missing facility is using transformation rules, see this thread.

@bagra 

It does it by pattern matching. If you want to look at a "bit" try:

infolevel[patmatch]:=3:
with(inttrans):
inttrans[invlaplace](s^(-2.3)/(s+c),s,t);

In other words, it is not a procedure implementing an algorithm for an analytic calculation, but it is looking at a table, using a result (general pattern) already computed elsewhere.

This interruption occurs at automatic simplification time, i.e. before any evaluation or program execution:

> '2/0';
Error, numeric exception: division by zero

As such, I think that it is unavoidable.

If you keep symbolic the coefficients of the powers of p, like:

Pol:=f3(x,y)*p^3+f2(x,y)*p^2+f1(x,y)*p+f0(x,y);

then kw(Pol) evaluates quickly. Next, you just need to evaluate its result with the explicit values, like eval(k,f3(x,y)=..., f2(x,y)=..., f1(x,y)=..., f0(x,y)=...]), which is also quick.

You can use this one:

solve({x^2+y^2+z^2 = 3, x+y+z = 3}, {x,y,z},parametric,real);
                    [[z = 1, y = 1, x = 1]]

See ?solve,parametric

Under the Maple installation directory there is a subdirectory named afm with files named Courier, Courier-Bold, etc.

A single rule works also for k=1:

> ee:=(c^2+a^2-b^2)*(a^2-c^2)^3*(a^2+c^2)^3:
> e2:=(c^2+a^2-b^2)*(a-c)^3*(a+c)^3:
> r:=(X::nonunit(algebraic)^k::integer+Y::nonunit(algebraic)^k::integer)^n::integer
> *(X::nonunit(algebraic)^k::integer-Y::nonunit(algebraic)^k::integer)^n::integer
> =(X^(2*k)-Y^(2*k))^n:

> applyrule(r,ee);		      
                             4    4 3   2    2    2
                           (a  - c )  (a  - b  + c )

> applyrule(r,e2);		      
                             2    2 3   2    2    2
                           (a  - c )  (a  - b  + c )

Yes, I beleive that a command for functional taylor expansion is missing. The following sketched procedure may help in the case of linear derivative terms:

> ftaylor:=proc(ex::algebraic,fs::set,n::posint)
> local ex1,d,
> fn:=(x->op(0,x))~(fs),
> s:={diff=d} union ((x->x)=(x->op(0,x)))~(fs);
> TypeTools:-AddType(d,'d(Or(d, algebraic), name)');
> ex1:=evalindets(subs(s,ex),d,LargeExpressions:-Veil[K]);
> ex1:=mtaylor(ex1,fn,n);
> ex1:=LargeExpressions:-Unveil[K](ex1,infinity);
> subs((rhs=lhs)~(s),ex1);
> end proc:

> ex := diff(f(r), r$2) + exp(-f(r))*(1 - g(r))^2;
                         / 2      \
                         |d       |                        2
                   ex := |--- f(r)| + exp(-f(r)) (1 - g(r))
                         |  2     |
                         \dr      /

> ftaylor(ex,{f(r),g(r)},2);
                         / 2      \
                         |d       |
                         |--- f(r)| + 1 - 2 g(r) - f(r)
                         |  2     |
                         \dr      /

> ex := diff(f(r), r$2) + diff(g(r), r$4)+(1 + g(r))^4*exp(f(r))/(1+h(r));
                   / 2      \   / 4      \             4
                   |d       |   |d       |   (1 + g(r))  exp(f(r))
             ex := |--- f(r)| + |--- g(r)| + ---------------------
                   |  2     |   |  4     |         1 + h(r)
                   \dr      /   \dr      /

> ftaylor(ex,{f(r),g(r),h(r)},2);
               / 2      \   / 4      \
               |d       |   |d       |
               |--- f(r)| + |--- g(r)| + 1 + f(r) + 4 g(r) - h(r)
               |  2     |   |  4     |
               \dr      /   \dr      /

That vertical "cliff" is a "joined" branch cut. I do blame the Maple people for this as it does not seem like a such difficult issue. What is needed is the introduction of an adaptive grid in 3d plots, a fairly standard technique that Mathematica has implemented many years ago and it uses as a key ingredient in its comparative marketing (see e.g. this thread)

Because the interface and the kernel communicate via localhost.