The origin of this error message is `plots/display` line 38:

> stoperror(traperror["integer"]):
> Student[Calculus1]:-Tangent(tan(3*x)-5*exp(-x^3),x=0,output=plot,
  gridlines=true,caption="");
Error, integer or integer range expected in op list
`plots/display`:
  38       opts := [op(opts), op(axisopts)]
DBG> axisopts
[axis[1] = [tickmarks = piticks]],
gridlines = true
`plots/display`:
  38       opts := [op(opts), op(axisopts)]
DBG> quit

As you see, axisopts is a sequence of two expressions, where the first is a list. So, it produces the same error as this toy example:

> op([a],b);
Error, integer or integer range expected in op list

Using the inert form `%mod` is also a good way to get control on the sequence of evaluations, placing them in the desired order:

> value(subs(m=21,`%mod`(m, 4)));
                                       1

As setting d^2=0 and its consequences (d^3=0, etc) is a "polynomial" operation, may be that a simplification with side relation is a good way:

> lhs(myeq)=map(simplify,rhs(myeq),{d^2=0});
                                        2       mu[m](t)
 2                              mu[p](t)  J sin(--------)
d                mu[m](t)                        phi[0]     I_b d
--- mu[m](t) = - -------- + 1/2 ------------------------- + -----
  2               C_J L                          2          2 C_J
dt                                     C_J phi[0]
                    mu[m](t)
           -2 J sin(--------) L - Phi[xx]
                     phi[0]
     + 1/2 ------------------------------
                       C_J L

I think that these different options should be compared for efficiency against your actual expression.

Well, yes, there are some hidden traps...In this case the documentation in ?Intat is misleading. The calling sequence states:

Intat(expr1, x=expr2)    # inert form

But actually, Intat is active (evaluates to a procedure):

> showstat(Intat);
Intat := proc(f::algebraic, dx_at_t::(symbol = algebraic))
   1   'procname(args)'
end proc

And the type check of the argument is causing the error message that you get. In other words the rule that I have written in the linked thread works because Int is inert, the same as Sum, while Intat is active:

> whattype(eval(Int));
                                     symbol
> whattype(eval(Intat));
                                   procedure

There are two methods of writing rules involving active function calls. One is using unevaluation quotes as Carl did. The other way is using the inert form of the command by means of the inertization prefix %, like:

> ToSumInt:=
>      %Intat(
>            A::algebraic*Sum(v::algebraic,r::{name,equation})*
>            B::algebraic,u::equation
>      )= Sum(%Intat(A*v*B,u),r)
> :
> J:= %Intat(f(xi)*Sum(g(n*xi), n), xi= x);
                              x
                             /        /-----        \
                            |         | \           |
                      J :=  |   f(xi) |  )   g(n xi)| dxi
                            |         | /           |
                            |         |-----        |
                           /          \  n          /
> 
> applyrule(ToSumInt, J);
                                   x
                          -----   /
                           \     |
                            )    |   g(n xi) f(xi) dxi
                           /     |
                          ----- /
                            n

The difference is that the number of levels of unevalution quotes needed to make it work may depend on some non obvious issues, while the method of the inertization prefix seems more systematic (and shorter to type).

Yes, multiple substitution equations can be used "at once" for algsubs through the foldr trick like:

> f:=x*y+x^2+y^3:
> foldr(algsubs,f,x=x1, y=x2);
                                 3     2
                               x2  + x1  + x1 x2

Certainly, this limitation of algsubs is a consequence of its development being frozen for over 15 years. 

Yes, this is a rule that makes it (as you have posted pictures, I will not type your example):

ich_si:=Int(A::algebraic*Sum(v::algebraic,r::{name,equation}),
u::{name,equation})=Sum(Int(A*v,u),r):

> J:=Int(f(x)*Sum(g(n)*h(x),n),x);
                              /      /-----          \
                             |       | \             |
                       J :=  |  f(x) |  )   g(n) h(x)| dx
                             |       | /             |
                             |       |-----          |
                            /        \  n            /
> applyrule(ich_si,J);
                          -----   /
                           \     |
                            )    |  f(x) g(n) h(x) dx
                           /     |
                          ----- /
                            n

This effect can be achieved by means of the InertForm package plus some transformation rules. For instance:

> r:= `%*`(`%^`(a::algebraic, b::algebraic), `%^`(a::algebraic,c::algebraic))=
`%^`(a,`%+`(b,c)):
> use InertForm:-NoSimpl in 2^3*2^4; end;
                             %*(%^(2, 3), %^(2, 4))
> i1:=applyrule(r,%);
                             i1 := %^(2, %+(3, 4))
> InertForm:-Display(%);
                                     (3 + 4)
                                    2
> evalindets(i1,specfunc(anything,`%+`),value);
                                    %^(2, 7)
> InertForm:-Display(%);
                                        7
                                       2

Note that for simple numeric computations like in this example, unevaluation quotes do not prevent the operation of the automatic simplification. E.g.:

 '2^3*2^4';
                                      128

Basically, I agree with acer exposition about pro and cons of applyrule and simplify. Namely, simplify with side relations is strong with polynomial expressions (computing Groebner basis), but simplify also may mess expressions by its other transformations. And applyrule strong point is targeting pattern instances which may not be subexpressions, but it is too much syntactically based rather than mathematical. Hence it would be desirable to combine the strong points of both.

For OP's and acer's examples, the idea is to make a rule that applies simplify on the polynomial part only. It requires a couple of tricks:

> T2:=ee->value(applyrule1(z^(m::integer)*conjugate(z)^(n::integer)
>                  = %simplify( z^m*conjugate(z)^n, {z*conjugate(z)=x} ),ee)):

> f1:=conjugate(z)^2*z^2:
> T2(f1);
                                        2
                                       x

> expr:=conjugate(z)*z^2*(ln(2*z)):
> T2(expr);
                                  x z ln(2 z)

The first trick is to use in the rule the inert form %simplify as applyrule does not handle/wrap simplify properly, passing to it the symbolic exponents m,n rather the actual integers. The second trick is using the custom version applyrule1, that applies the rule only once, avoiding the fix point design bug.

Yes, such a facility is missing in Maple. A workaround is:

> solve({0<x, x<1, x^2+y^2 - 1 > 0}, {y}, parametric);
           {                    []                            x <= 0
           {
           {           2     1/2       2     1/2
           { [[y < -(-x  + 1)   ], [(-x  + 1)    < y]]        x < 1
           {
           {                    []                            1 <= x

> minimize(-(-x^2+1)^(1/2),0<x,x<1);
                                       -1
> maximize((-x^2+1)^(1/2),0<x,x<1);
                                       1

Note also that there are problems in checking:

> is(y<=-1 or y>=1) assuming 0<x, x<1, x^2+y^2 - 1 > 0;
                                      FAIL

By the way, Reduce has the interesting package Redlog on this subject.

I would not place too much hope on improvements for the latex facility in future versions. The same output that you show  was produced already by Maple 9 (11 years old). And Maplesoft bet is for TypeMK, rather than TeX. So, in my opinion, a more practical option than wait or hand edit is to use the Algolib LaTeX facility, see this recent thread:

> MADLaTeX:-latex(v1);
\bigl[\tau _{\lambda,1}^{2},\tau _{\lambda,2}^{2},\tau _{\lambda,3}^{2},
\tau _{\lambda,4}^{2},\tau _{\lambda,5}^{2}\bigr]

This is a recurrent request. As stated, the answer is no. See e.g. this thread and linked ones therein.

It seems that you have hit a bug in match. At some point, the new parameter qq, which is dividing, is substituted by 0, raising the exception:

> Eq1 := (diff(psi(y), y, y, y, y))/qq-M^2*(diff(psi(y), y, y))-b*y = 0:
> bcs1:=psi(0)=0,(D@@2)(psi)(0)=0,psi(h)=-F/2,D(psi)(h)=A:
> res1:=(dsolve(Eq1)):
> res2:=(dsolve({Eq1,bcs1},psi(y))):
> stoperror("numeric exception: division by zero"):
> match(rhs(res2)=rhs(res1),y,s);
Error, numeric exception: division by zero
`match/InvRed1`:
   3       if testeq(subs(si,prevsubs,ei)-expr) then
             ...
           else
             ...
           end if
DBG> subs(prevsubs,qq)
0
...

Somehow, using instead qq^2 goes around it:

> Eq1 := (diff(psi(y), y, y, y, y))/qq^2-M^2*(diff(psi(y), y, y))-b*y = 0:
> bcs1:=psi(0)=0,(D@@2)(psi)(0)=0,psi(h)=-F/2,D(psi)(h)=A:
> res1:=(dsolve(Eq1)):
> res2:=(dsolve({Eq1,bcs1},psi(y))):
> match(rhs(res2)=rhs(res1),y,s):
> s;
              2                   2          3        2
            qq  exp(M qq h) (6 A M  h + 2 b h  + 3 F M )
{_C1 = 1/6 -----------------------------------------------,
                        2                            2
           M exp(M qq h)  h qq + M qq h - exp(M qq h)  + 1
...
    

The correct sum up of the cited thread is that it does not work only when using the Standard GUI, but it works fine when using the command line interface (CLI) or the Classic GUI, which (fortunately) still use the old code, even in Maple 18.

Some comments about the symbolic manipulation complaints. No hand edit is needed here:

> eqs:=[3*a+4*b = 3*x, 5*a+7*b = 7*x]:
> eqs2:=expand~(eqs /~ x);
                              3 a   4 b      5 a   7 b
                     eqs2 := [--- + --- = 3, --- + --- = 7]
                               x     x        x     x

And certainly, algsubs needs several improvements. Its development has been basically frozen for over 15 years. You can use this workaround by means of foldr:

> foldr(algsubs,eqs2,a/x=z1,b/x=z2);
                       [3 z1 + 4 z2 = 3, 5 z1 + 7 z2 = 7]

Since this evening (March 25 2014) the email inboxes associated with my accounts have received tens of email notifications corresponding to changes in threads up to about one month old.