No, in the OP's system, everything except t are constants. So in your example, a and B should be constants, and B=-a/t is not a constant. So, it is not a solution.

The issue here is that the equation has to hold for every t. And, each different power of t is functionally independent. So, its coefficient must vanish.

The issue here is that the equation has to hold for every t. And, each different power of t is functionally independent. So, its coefficient must vanish.

I'll show it for the first equation:

eq1:=B*(B-1)*t^B+3*a*B*t^B-6*a+12*a^2 :

Here, either all terms are constant, i.e. B=0 and vanish together:

solve(eval({eq1},B=0));
                          {a = 0}, {a = 1/2}

Or B<>0 and the terms with the same power t^B and constant terms vanish separately:

indets(eq1,And(`^`,satisfies(u->op(1,u)=t))):
map[3](select,has,[op(eq1)],%) union {remove(has,[op(eq1)],t)}:
(factor@`+`@op)~(%);
solve~(indets~(%,`+`)):
solve(op~(%));

                   B
                 {t  B (B - 1 + 3 a), 6 a (-1 + 2 a)}

                         {B = -1/2, a = 1/2}

You can then repeat similar steps for the other equations.

I'll show it for the first equation:

eq1:=B*(B-1)*t^B+3*a*B*t^B-6*a+12*a^2 :

Here, either all terms are constant, i.e. B=0 and vanish together:

solve(eval({eq1},B=0));
                          {a = 0}, {a = 1/2}

Or B<>0 and the terms with the same power t^B and constant terms vanish separately:

indets(eq1,And(`^`,satisfies(u->op(1,u)=t))):
map[3](select,has,[op(eq1)],%) union {remove(has,[op(eq1)],t)}:
(factor@`+`@op)~(%);
solve~(indets~(%,`+`)):
solve(op~(%));

                   B
                 {t  B (B - 1 + 3 a), 6 a (-1 + 2 a)}

                         {B = -1/2, a = 1/2}

You can then repeat similar steps for the other equations.

You can get its code by:

kernelopts(opaquemodules=false):
showstat(numtheory:-invrec);

But I cannot say what it is as I am not familiar with this subject.

About why it is undocumented, who knows? I have read from developers quite strange arguments justifying, or even praising, the undocumentation. Indeed, many (really many) commands are undocumented. And some of them may be much more useful than documented ones.

By other evidence, you mean comparative reviews of Linux vs Windows on 64 bits/multiprocessor platforms? If so, do you have some pointers?

I find this same 10^8 limit in 32-bits Maple. Shouldn't it be higher in 64-bits?

With that terminology, an option "strict" would be useful.

I think inequality should be strict, otherwise:

isconvex(x);
                                 true

Another issue would be parameters, on which assumptions may hold as here:

isconvex( (x-a)^2 ) assuming a::real;

Error, (in assuming) when calling 'isconvex'. 
Received: 'testing against an invalid type'

Probably, it would be better to state explicitly the variable as another argument.

Use 'n'['i']:

n:=4:i:=3:

n[i];

                                 4[3]

'n'['i'];

                                 n[i]

Use 'n'['i']:

n:=4:i:=3:

n[i];

                                 4[3]

'n'['i'];

                                 n[i]

But a compleximplicitplot say, would be a useful addition, I think. And simple to implement.

But a compleximplicitplot say, would be a useful addition, I think. And simple to implement.