@jud See:

Todd–Coxeter algorithm - Wikipedia

@Carl Love The fact that

sys:=[a*x1^3 + b*x1^2 + c*x1 + d, a*x2^3 + b*x2^2 + c*x2 + d, a*x3^3 + b*x3^2 + c*x3 + d, x1*x2*x3 = -d/a, x1 + x2 + x3 = -b/a, x1*x2 + x1*x3 + x2*x3 = c/a]:
solve(sys, {x1, x2, x3}, explicit);

does not work, is a weakness of solve.
It is easy to see (but not for a CAS) that sys is equivalent to sys[4..6], which works!

@Carl Love 

g := (x, T) -> T*x + x^2:  #just an example
dgdx1:=(x,T) -> D[1](g)(x,T);
dgdx2:=  D[1](g);
dgdx1(1, 2);  # 4
dgdx2(1, 2);  # 4

g := (x, T) -> T*x + 7*x^2:
dgdx1(1, 2); # 16
dgdx2(1, 2); # 4

For a fixed g, dgdx2 is of course more efficient, but I don't think this matters here.

Your odetest examples are not correctly treated. You cannot use asympt when the series solution is around a finite point (e.g. 'point'=0). asympt does a series expansion around infinity!
Note also that not all ode solutions have series expansions; e.g. for Ex 6, the series can be obtained only with MultiSeries:-series,
so, for x>0 (series and dsolve cannot do it).

@acer  Of course, but that is what the user has asked.

@Axel Vogt Your last command should be:
MultiSeries:-asympt(%, x, 6);
or simply,
asympt(%, x, 6);

Actualy, odetest(sol, ode)  does essentially the same thing.

@nm All your "positive" examples are regular series or Puiseux series.
The solution of the ode in the question is not of these types, and I suspect that odetest rejects it.
But the asympt approach is acceptable in my opinion and works.

@smithss  This one cannot have a solution: there are more columns than colors!

@Carl Love Actually the max number of permutations used is small:

(9!/(3!*2!*2!)) * 6 = 90720

because once a permution if found for a column, it is kept.
The puzzle can be easily solved by hand.

It would be interesting to find a puzzle which cannot be solved this way!

@C_R It would not be a good idea to simply return infinity, because the arithmetic with oo is complicated.
This is why there is try ... end try.  See also ?events
Example

try
  EllipticK(1)
  catch "numeric exception: div":
  infinity;
end try;

      infinity

@jud What I get is:

@jud  Yes, it seems that in newer versions, DrawSubgroupLattice outputs numbers (1,2,...) instead of symbols (`1`,`2`,...); unfortunately I have not tested Carl's code before posting.
You will have to try my approach which works.

@jud Because you are using the document mode, create a prompt and paste the code there.

@ecterrab Very nice, congratulations!

I was curious to see why Sum=add is needed (instead of value).
It seems that sum has problems with pochhammer. If we replace pochhammer with P,  (and then back), value works.
Here is an example:

S:=Sum(pochhammer(2*k - n + 1, 2*n - 2*k)*pochhammer(3 - k, k)/((n - k)!), k = 0 .. n):
value(%); # ?
#                               0
seq( value(eval(S,n=N)), N=1..6 );
#                       2, 6, 12, 24, 0, 0

The result of value(S) should be  2*n*(n - 1)/GAMMA(-n + 5)  (instead of 0)
which is actually obtained using  assuming n::posint

In this case, the correct values can be obtained with limit insted of eval.

(The situation is similar to sum(k, k=1..n) where n is also "assumed" integer).

@ecterrab In order to use this workaround I had to replace ex1 with allvalues(ex1) in ex2 due to the Sum(..., alpha=RootOf(...)). 
BTW, in an older Maple version I have on a small laptop, your first workaround worked for the "assuming" example (applied blindly!); here ex1 contains a hypergeom function, and diff(...) is absent in ex1. It seems to be a better answer (at least in this case). Maple is interesting!

Best regards,
vv

Edit.

The answer of ex1 contains an inert sum and diff(u, y$p), for p in 0..k.
But in this case (when diff is accepted) a much simpler symbolic answer is

ans := pochhammer(-j,j)*Diff((y^2)^j*(x*y^2+2)^(-1-j),y $ k);
value(eval(ans,[j=2,k=4,x=0,y=0]));
        6

This one is not fragile :-)