I have run both .mpl input files, just as posted, in Maple 16.01 CLI on Linux Mint 13 32-bit many times. I find that both execute quite quickly, in about 0.8 s (gc output after quit) with small session to session changes. And using these files as input for the Standard GUI, the execution times are similar. I have also run these files in previous Maple versions CLI and found that that both run even faster in Maple 14.01 or earlier, taking about 0.6s, and using less memory.

So, could it be a 64-bit issue? (I cannot check it at this time).

Because routines for symbolic manipulation of sums (a "SummationTools" package) are missing. The most efficient workaround is likely using transformation rules as here:

combine_summand:=A::algebraic*Sum(a::algebraic,eq1::equation)+
B::algebraic*Sum(b::algebraic,eq1::equation)=Sum(A*a+B*b,eq1):

S:=Sum(cadj[i]*vfinal[i], i = c .. d)-(Sum(cadj[i]*vinit[i], i = c .. d)):
applyrule(combine_summand,S);

                    d
                  -----
                   \
                    )   (cadj[i] vfinal[i] - cadj[i] vinit[i])
                   /
                  -----
                  i = c

factor(%);
                        d
                      -----
                       \
                        )   cadj[i] (vfinal[i] - vinit[i])
                       /
                      -----
                      i = c

Note that for such symbolic computations, the inert form Sum is better.

I think that there is no command working exactly like that. But some programmatic options were described in these threads (and those linked therein):

Prevent sections in maple from executing in Maple 13

automatic execution

I think that there is no standard way. Actuallty, I find that the available functionality for handling records is rather limited. Or may be that it exists but is not documented. In any case, it makes this structure less useful.

For substitutions, I would not overload subs, but write a procedure with a different name. May be something as in this toy example:

recordsubs:=proc(r::record,eq::equation)
local ex,exs:
ex:=[exports(r)];
exports(r,instance);
exs:=subs(eq,[%]);
Record(op(zip(`=`,ex,exs)));
end proc:

R := Record( 'a', 'b' ):
R:-a := <c,d,e>;
R:-b:=c;

Rs:=recordsubs(R,c=2);
                                           [2]
                                           [ ]
                          Rs := Record(a = [d], b = 2)
                                           [ ]
                                           [e]
Rs:-a;
                                      [2]
                                      [ ]
                                      [d]
                                      [ ]
                                      [e]

Note that the Record structure is a module and the fields are exported local names, so a substitution on global names will not work.

No, you can't "persuade" Maple to simplify these double sums to zero. Presumably, such capability would make use of the missing "SummationTools" package (which is probably the second most requested symbolic computation kind of facilities after abstract algebra).

However, a procedure for this purpose could be written. The main ingredients would be 1. checking the symmetry of the sumation region, and 2. checking the symmetry of the summand. In this case, finding that the region is symmetric and the summand is antisymmetric. For the latter step you could do something like the following split into symmetric and antisymmetric parts:

> s:=(i,j)-> m[i]*m[j]*(x[i] - x[j]):
> 
> split_sym:=proc(s,i,j)
> local sym,asym:
> sym:=1/2*(s(i,j)+s(j,i));
> asym:=1/2*(s(i,j)-s(j,i)):
> [sym,asym];
> end proc:
> 
> split_sym(s,i,j);
[1/2 m[i] m[j] (x[i] - x[j]) + 1/2 m[j] m[i] (x[j] - x[i]),
    1/2 m[i] m[j] (x[i] - x[j]) - 1/2 m[j] m[i] (x[j] - x[i])]
> simplify(%);
                      [0, m[i] m[j] x[i] - m[i] m[j] x[j]]

The error in Preben's example arises because the calling stack limit is reached. I.e. the stack space is the exhausted one rather than the total memory space. See in ?kernelopts about stacklimit:

> W:=Vector(datatype=string);
                                    W := []
> W(1):="1";
Execution stopped: Stack limit reached.

Note that this error arises before than the type of the rhs is checked against the rtable datatype, as the same error arises here:

> W(1):=a;
Execution stopped: Stack limit reached.

And this error that stops the kernel, is different to this other error about bounds:

> W(0):="1":
Error, index out of bounds

Yet, this problem seems somewhat related to bounds. Debugging shows that the rtable constructor takes the unusual dimension range 1..0:

> stopat(`print/rtable`,21):
> W:=Vector(datatype=string);
[]
`print/rtable`:
  21*        RTABLE(addressof(A),MATRIX([seq([`print/rtable/elem1`(A,[i])],i = dims)]),st)
DBG> dims
1 .. 0
`print/rtable`:
  21*        RTABLE(addressof(A),MATRIX([seq([`print/rtable/elem1`(A,[i])],i = dims)]),st)

So that an Array with this range also causes this stack error:

> W:=Array(1..0,datatype=string);
                                    W := []
> W(1):="1":
Execution stopped: Stack limit reached.

While no such problem occurs for the range 1..1:

> W:=Array(1..1,datatype=string);
                                   W := [""]
> W(1):="1";
                                   W := ["1"]

However, this unusual range could be only part of the story, as it occurs also for the other datatypes that do not generate this stack error. In all, I think that this is a bug in the kernel specific to the datatype string. And it occurs already in Maple 12, where programmer indexing was introduced.

As how could this bug have evaded detection, well, note that bug undetection is a rather common circumstance. Many bugs are detected after release, sometimes only after many years. In part, probably, as testing is not good enough, betatesters included. On the other hand, many bugs may be detected but remain unfixed. But if this one is confirmed as a kernel bug, may be probably fixed soon.  

Never did that, but I was curious. So I made a quick experiment in Linux. LibreOffice Impress admits a TeX-like input for math. So, I used the output of the latex command for some simple expressions, and by a minimal editing I have got the Maple output in the presentation. Then, I exported to a ppt format file and got it fine. It may be better than grabbed screenshots as the source of the math in Impress is editable. Whether this is sane enough is a subjective issue...

I have no such problem here running Maple V R4 or R5 GUIs on Windows XP 32-bit (in a Pentium machine). On the other hand, Windows XP 32-bit can run 16-bit applications. Most likely, that is not the cause of the problem with R2 or R3 GUIs.

If you have time, you may look at the Turbo Pascal 7  Runtime Error 200 (divide by zero). bug. If it is not the exact problem here, it is close.

I have looked at this problem a little bit some 7 years ago. I think that the problem was the language in which those GUIs were written and compiled (i.e. the lack of support for features in newer processors). In particular, the versions of Maple V R2 and 3 that I have were designed to run on Windows 3.1 (a 16-bit patch on 8-bit DOS). So, they are a predecessor to the 32-bit Classic GUI. Indeed, afterwards, the Maple V R4 GUI required the installation of the Win32s patch on top of Windows 3.1.

I made a try to make it run on Wine (from Linux) but did not worked. Never had time to try a Virtual Machine approach. So, I wonder also.

I have a fair number of my research calculations and presentation stuff of that time in those .ms worksheets. And I would find nice being able to run them in their original form. 

Yes, in a Pentium machine, on Windows XP 32-bit, Maple V R2 and R3 GUIs produce that error but their CLIs work fine for me.

See this thread for diverse (more or less programmatic) ways of creating a displayed table. Which is the best may depend on several factors, including subjective ones.

Indeed, the indefinite integral is computed:

> int(x^4/(4*x^5+2), x);
                                          5
                               1/20 ln(2 x  + 1)

and actually, the method FTOC does compute internally the value of the definite integral by taking the limits of this primitive function. But then, the discontinuity checker fails at deciding whether this function is continuous within the integration interval:

> kernelopts(opaquemodules=false):
> trace(IntegrationTools:-Definite:-Integrators:-FTOC:-HandleDisconts):
> int(x^4/(4*x^5+2), x=0..1,method=ftoc);
{--> enter HandleDisconts, args = 1/20*ln(2*x^5+1), 1/2*x^4/(2*x^5+1), x, 0, 1
, table([(UnevaluatedIntegral)=UnevaluatedInt(x^4/(4*x^5+2),x = 0 .. 1,method =
ftoc),(AllSolutions)=false,(OriginalParms)=[AllSolutions = false, 
CauchyPrincipalValue = false, continuous = false, method = ftoc],(continuous)=
false,(CPV)=false,(formula)=true,(CauchyPrincipalValue)=false,(mode)=default])
, false
                         5
disconts := {[RootOf(2 _Z  + 1, index = 1), NULL, NULL],
                5
    [RootOf(2 _Z  + 1, index = 2), NULL, NULL],
                5
    [RootOf(2 _Z  + 1, index = 3), NULL, NULL],
                5
    [RootOf(2 _Z  + 1, index = 4), NULL, NULL],
                5
    [RootOf(2 _Z  + 1, index = 5), NULL, NULL]}
<-- exit HandleDisconts (now in Apply_Main) = FAIL}
                            4
                           x
                    int(--------, x = 0 .. 1, method = ftoc)
                           5
                        4 x  + 2 

The workaround is disabling this check by setting the option continuous=true:

> int(x^4/(4*x^5+2), x=0..1,continuous=true);
                                   1/20 ln(3)

So, the reasons are on the one hand the problem handling the roots of 2*x^5+1 as candidates for discontinuities of the primitive function. And on the other hand, a problem of design. As the discontinuity checker is unable to decide, the integrator hides this weakness by returning unevaluated. But how could a normal user guess this weakness and deal with it? In my opinion, it would be more useful and honest returning the result already computed with a warning message about the failure of the discontinuity checker and the need for checking this result by other means.

I do not think that the way Maple handles highlighting in the Standard GUI is actually "smart", but derives from the structure of the internal  representation of the expressions. In particular, for input, it depends on the mode: 1-D vs 2-D, and for the latter its internal representation is TypeMK (a derivative from MathML), which is quite involved and not well designed, to my taste. So, I understand that it is an intrinsic "feature" of this GUI that cannot be disabled.

Then, for a platform that has no Classic GUI available like yours, the first option is using 1-D input. A better option would be using a text editor, and then pasting the code into the Standard GUI. Or even better, using an IDE or IDE-like editor and injecting the code into the interface.

The method of transformation rules may be more systematic (no need of unnecessary assumptions) and simpler (no need of accounting suboperands):

> r:=[(tau[a]^2*wn^2+1)^p::fraction=a^p, (tau[b]^2*wn^2+1)^q::fraction=b^q]:
> (simplify@applyrule)(r,eq);
                                    1                   2         2
           cos(wn t[2] + arctan(---------)) wn (a tau[b]  - tau[a]  b)
                                wn tau[b]
         - -----------------------------------------------------------
                                     3/2  1/2
                                    b    a