The problem is that the list of (special) functions in ?convert,to_special_function misses tens of function names shown in the list

`convert/to_special_function/hierarchy`["function"];

including:

AngerJ, Beta, Chi, Ci, Dirac, EllipticCE, EllipticCK, EllipticCPi, EllipticF,
EllipticModulus, EllipticNome, EllipticPi, FresnelC, FresnelS, Fresnelf,
Fresnelg, GaussAGM, Heaviside, HeunB, HeunBPrime, HeunC, HeunCPrime, HeunD,
HeunDPrime, HeunG, HeunGPrime, HeunT, HeunTPrime, Hypergeom, ...

Presumably, conversions to these functions are available, but I have not checked every case.

I think that there is no topic:

?convert/to_special_function/hierarchy

or the like. This arises by inspecting the code:

showstat(`convert/to_special_function`,12);
...
 12     CLASSES := `convert/to_special_function/hierarchy`["classes"];
...

Both 'Si' and 'Ssi' are already within the "Ei_related" class, so convert/Ei_related, that "converts" special functions not in this class, into Ei related functions, makes nothing.

I think that there is no topic:

?convert/to_special_function/hierarchy

or the like. This arises by inspecting the code:

showstat(`convert/to_special_function`,12);
...
 12     CLASSES := `convert/to_special_function/hierarchy`["classes"];
...

Both 'Si' and 'Ssi' are already within the "Ei_related" class, so convert/Ei_related, that "converts" special functions not in this class, into Ei related functions, makes nothing.

I get instead a lengthy 5th order ODE that depends also on alp.

I get instead a lengthy 5th order ODE that depends also on alp.

If piecewise output is not liked for default, what about as an option to 'int'?

'Si' is in this list:

`convert/to_special_function/hierarchy`["function"];

'Si' is in this list:

`convert/to_special_function/hierarchy`["function"];

If, as it seems, the order of precedence of the operators, as given in ?operators,precedence, is built into the kernel, it cannot be altered. 

is Mathematics, is an interpretation :)

These are computational representations of mahematical objects. The rules of the computational systems are the creation of one or more developers. So, as I see it, they also convey hints about their minds, the way they think.

So, the answer to why? may be complex. Hopefuly not.

The operators &and, &or have the same precedence and are left associative (?operators,precedence). Then:

with(Logic):
p ∧ q ∨ r;
r ∨ p ∧ q;

                           r ∨ (p ∧ q)
                           q ∧ (r ∨ p)

PS This typesetting effect was unexpected...

If an analytic solution for the actual system of equations is not available, may be, for a relativistic problem, that a change to advanced and retarded variables may help. Eg:

with(PDETools,dchange):
tr:={x=(U+V)/2,t=(U-V)/2};
PDE1:=dchange(tr,PDE);

in your toy system gives you equations where you may take U or V as a "time" variable for the numeric routine.

PS: Actually this toy system is a single equation: diff(u(x, t), t,x) = u(x, t).

If an analytic solution for the actual system of equations is not available, may be, for a relativistic problem, that a change to advanced and retarded variables may help. Eg:

with(PDETools,dchange):
tr:={x=(U+V)/2,t=(U-V)/2};
PDE1:=dchange(tr,PDE);

in your toy system gives you equations where you may take U or V as a "time" variable for the numeric routine.

PS: Actually this toy system is a single equation: diff(u(x, t), t,x) = u(x, t).

This FAQ page might give a hint, and the version for Maple 9.5 was more explicit:

When Maple starts, it sets the maximum amount of memory Java may potentially use based on the amount of physical memory in the machine. If that maximum is too high, Java refuses to start, so on machines with lots of physical memory (more than 1GB), Maple will not start either. This problem has been reported to Sun. In the meantime, we have created a new program launcher that respects this limitation on the maximum amount of memory that could ever be used by Java, and thus avoids the problem. This change does not affect the amount of memory available to non-Java components of Maple, including the math engine, which will still take advantage of all the machine's internal memory when solving large problems.

So, if there is an upper limit to the memory that Java may use, may be that this imposes a upper limit to the size of the Standard worksheet that can be loaded, independently of the amount of the physical memory.

This FAQ page might give a hint, and the version for Maple 9.5 was more explicit:

When Maple starts, it sets the maximum amount of memory Java may potentially use based on the amount of physical memory in the machine. If that maximum is too high, Java refuses to start, so on machines with lots of physical memory (more than 1GB), Maple will not start either. This problem has been reported to Sun. In the meantime, we have created a new program launcher that respects this limitation on the maximum amount of memory that could ever be used by Java, and thus avoids the problem. This change does not affect the amount of memory available to non-Java components of Maple, including the math engine, which will still take advantage of all the machine's internal memory when solving large problems.

So, if there is an upper limit to the memory that Java may use, may be that this imposes a upper limit to the size of the Standard worksheet that can be loaded, independently of the amount of the physical memory.