It was a first version (before going to dinner) to test that simplest case. Here is a second version working, in pinciple, for expressions:

fac:=proc(ex,f1,f2)
local fas;
fas:=(e,f,g)->subs(op(1,FunctionAdvisor(specialize, f,g)),e);
fas(ex,op(indets(ex,specfunc(anything,f1))),f2);
end proc:

fac(ln(4*HeunB(alpha,0,0,0,2*z)+5),HeunB,WhittakerM);

in that computers playing it, as I understand, massively explore the braches of possible movements and choose the  "best".

in that computers playing it, as I understand, massively explore the braches of possible movements and choose the  "best".

I think that it is more humans that make calculations by hand vs humans that program computers.

I think that it is more humans that make calculations by hand vs humans that program computers.

this split in computational paths occurs (more precisely I have checked Maple 9.52).

With Maple 9.03:

int((x^2)^(1/3),x);

goes through Risch integration and produces:

                                         5/3
                                      3 x
                                      ------
                                        5

this split in computational paths occurs (more precisely I have checked Maple 9.52).

With Maple 9.03:

int((x^2)^(1/3),x);

goes through Risch integration and produces:

                                         5/3
                                      3 x
                                      ------
                                        5

Tracing a bit with

infolevel[all]:=3:
trace(int):

I see that the computation paths with and without 1 are very different. Eg, without, it goes to:

PolynomialNormalForm:   "construct the differential polynomial normal form"

Tracing a bit with

infolevel[all]:=3:
trace(int):

I see that the computation paths with and without 1 are very different. Eg, without, it goes to:

PolynomialNormalForm:   "construct the differential polynomial normal form"

how it works. Ie the relationship between 'FunctionAdvisor' and 'convert'. Eg:

FunctionAdvisor(specialize, HeunB);

But

convert(HeunB(alpha,0,0,0,z),BesselI);

                       HeunB(alpha, 0, 0, 0, z)

how it works. Ie the relationship between 'FunctionAdvisor' and 'convert'. Eg:

FunctionAdvisor(specialize, HeunB);

But

convert(HeunB(alpha,0,0,0,z),BesselI);

                       HeunB(alpha, 0, 0, 0, z)

an explanation about the available options for implementation. And the reasons for the current choice, given this limitation on the precedence of the operators. May be that this was the best (or less bad option). It would be better, I think, than speculations about this subject.

Indeed, the question about reasigning precedence is quite interesting. But I wonder how far it is relevant to Maple, in the sense that it could be implemented some day.

I do not know whether  this is useful. I have tried with the package  Finding Minimal Sum for Boolean Expression, that uses a different representation:

minbool("pq+r");
Minimal sum: R + PQ
minbool("r+pq");
Minimal sum: R + PQ

as in Mathematics, but sadly these computational representations are not always faithful. May be that technical reasons, ie limitations of the underlying system/language,  among other issues, as discussed before, have a role.

Curiously, the former 'logic' package (available in Maple V) was also implemented using these &-operators. May be that there is no better option?

It would be nice that the author of the 'Logic' package post an explanation.

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.