A possible favorable interpretation of the fact that odetest gives 0 for a _Cnn solution of the ODE and <>0 for another constant:

1. In the case of _Cnn  the 0 result says that the solution is correct, but without mentioning that the intervals of validity must be found.
2. In the case of another constant (symbolic or numeric) the result of odetest allows to effectively find the correct interval(s) where the solution is valid.

It would be interesting to know whether this interpretation is correct (i.e. the behavior is intended) or we have a simple bug here.

It's an interesting catch. Vote up!
It seems that the _Cnn  constants are treated in a special manner by odetest.
So, odetest  will return   0  for   sin(sqrt(x) + _C123) ,  but nonzero   for other constants (numeric or symbolic).

I am not able to explain this behavior, but the corect result for odetest should be the nonzero one!  Because sin(sqrt(x)+C/2)  is a solution (assuming x>=0)  only for  sqrt(x)+C/2  in [-Pi/2, Pi/2]  mod 2Pi  
which is equivalent to cos(sqrt(x)+C/2) - abs( cos(sqrt(x)+C/2)  ) = 0  given by odetest.

You cannot replace _Z in a RootOf unless you also insert the new variable (otherwise a syntax error appears).
So,   RootOf(f(_Z))  -->  RootOf(f(n),n)

It it easy to do this, but it's useless because RootOf(f(n),n)  will be simplified automatically to the _Z version.

You are not allowed to expand like this. Actually the double sum, triple sum etc are all infinite, so the "resulting series" would be 1 - oo + oo - oo +  ...

As shown in another answer the product is "telescoping", hence easy to compute.
For other situations one may use the fact that for 0 < a(n)<1,
product(1 - a(n), n=1..infinity) = 0   iff   sum(a(n), n=1..infinity) = infinity. 

There is probably a copy&paste problem: args(k) should be args[k]
(or better  l := [args]).

You also have a syntax error in f()  [a ":" after proc()  not accepted in 1d].

But the main problem is that Object||n  are global symbols not the same with your local Object1,...

sys:=
[3*v^2-v*t*(v^2+3)-3*w^2+w*t*(w^2+3),v*(p*v^2+3)/(3*v^2+1)-w*(p*w^2+3)/(3*w^2+1),2*t-v*(p*v^2+3)/(3*v^2+1)-w*(p*w^2+3)/(3*w^2+1)]:
S:=unapply(sys,t):
P:=t -> eval(p,fsolve(S(t))):
plot(P, 0..2);

SolveTools:-SemiAlgebraic and some other commands in SolveTools (which are called by solve for inequalities) do not like infinity (==> errors).  Actually infinity is never needed here.

Edit. Here is a short procedure to remove the useless infinities:

CleanInfty:=proc(L::{list,set}(relation))
map(
  proc(r) local u; 
    if not has(r,infinity) then return r fi;
    u:=eval( r, (indets(r)=~0) );
    if is(u) then u:=NULL else u:=0<0 fi;
  end, L)
end;

Example:

S:={x<>10, -infinity<x , x<infinity, -infinity<y, y<infinity, x>-2}:
solve(CleanInfty(S), {x,y});
#SolveTools:-SemiAlgebraic(S,{x,y});

      {y = y, 10 < x},  {y = y, -2 < x, x < 10}

int((1-(-1)^floor(u))/(2*u^2), u = 1 .. X) assuming X>3:
limit(%, X=infinity);

          ln(2)

binomial(m,k)*a^(m-k)

The numerical integration routine for

is fooled by the fact that the integrand is 0 in the intervals [2k, 2k+1)  and stops the summation too early.

map(min, M, 20);

or maybe

map[inplace](min, M, 20);

You have used distinct strange names in the two files:

`#mover(mi("&Xi;"),mo("&uminus0;"))`
and
`#mover(mi("&Xi;",fontstyle = "normal"),mo("&uminus0;"))`;

I'd suggest to avoid in the future such names in files (you cannot see them properly in 2d input!).
The fix is simple:
 

restart;
read "sai.m";
`#mover(mi("Ξ"),mo("&uminus0;"))`:
`#mover(mi("Ξ",fontstyle = "normal"),mo("&uminus0;"))`:=%:
read "TKtm.m";
TKtm;

      0.106923339809255e-6*(diff(tau[1](t), t))^2

printlevel := 2; 
Equation := 4;
for i from 0 to Equation do 
for j from 0 to Equation do 
  C[i,j]:=coeff(coeff(H1,x,i),y,j)
end do end do;