Not sure what you mean, but these relationships can be solved:

solve(identity(C*sin(t+theta)=A*sin(t)+B*cos(t),t),[A,B]);
solve(op(%),{C,theta});
allvalues(%);

{C = (B^2+A^2)^(1/2), theta = arctan(B/(B^2+A^2)^(1/2),A/(B^2+A^2)^(1/2))}; {C = -(B^2+A^2)^(1/2), theta = arctan(-B/(B^2+A^2)^(1/2),-A/(B^2+A^2)^(1/2))};

Simpler expressions arise in the case of reals:

allvalues(%) assuming real;

Not sure what you mean, but these relationships can be solved:

solve(identity(C*sin(t+theta)=A*sin(t)+B*cos(t),t),[A,B]);
solve(op(%),{C,theta});
allvalues(%);

{C = (B^2+A^2)^(1/2), theta = arctan(B/(B^2+A^2)^(1/2),A/(B^2+A^2)^(1/2))}; {C = -(B^2+A^2)^(1/2), theta = arctan(-B/(B^2+A^2)^(1/2),-A/(B^2+A^2)^(1/2))};

Simpler expressions arise in the case of reals:

allvalues(%) assuming real;

something can be done, at least for "simple" cases like this one:

applyrule(A::algebraic*sin(t::algebraic)+B::algebraic
*cos(t::algebraic)=C*sin(t+theta),C1*sin(omega*t)
+C2*cos(omega*t)+C3);
                     C sin(omega t + theta) + C3

This way you do not get what C and theta are, though. For this, you may use 'solve/identity' 

solve(identity(A*sin(t)+B*cos(t)=C*sin(t+theta),t),[A,B,C,theta]);
     [[A = C cos(theta), B = C sin(theta), C = C, theta = theta]]

something can be done, at least for "simple" cases like this one:

applyrule(A::algebraic*sin(t::algebraic)+B::algebraic
*cos(t::algebraic)=C*sin(t+theta),C1*sin(omega*t)
+C2*cos(omega*t)+C3);
                     C sin(omega t + theta) + C3

This way you do not get what C and theta are, though. For this, you may use 'solve/identity' 

solve(identity(A*sin(t)+B*cos(t)=C*sin(t+theta),t),[A,B,C,theta]);
     [[A = C cos(theta), B = C sin(theta), C = C, theta = theta]]

The inversions of the equations below need a bit more care.

The inversions of the equations below need a bit more care.

The behavior in the neighborhood shows that there is no limit for q as a->1/3. There are lateral/directional limits:
 

limit(q,a=1/3,right);
                             1     (2/3)   (1/3)
                             -- 108      13     
                             54                 
limit(q,a=1/3,left);
                           1        (2/3)   (1/3)
                           -- (-108)      13     
                           54                    

Hence, it seems to me that the current result of 'eval' is a bug, and the result should be "undefined", consistent with the output of 'limit'.

Yes. I think that it is a rather serious bug. It would be desirable that, at least, a warning  about potential problems were issued in case that algorithmically it were not simple to decide for "undefined". Correctness (or at least not-incorrecteness) is priority. Of how much time savings are you thinking 1s?, 1 min? Probably it would take for the user much more time than that to realize of the bug and trace it back.

I think that 'eval' should check for 'limit' in case of doubt (apparently it is not doing that).

PS I think that you mean this statement in ?eval

Since eval does pointwise evaluation, eval cannot be used to evaluate an expression at a singularity. Use limit instead.
 

Well, somehow 'eval' should realize that there is a singularity to, at least, issue a warning. I do not see how it can be done without information about the neighborhood.

The background of this issue, is, as I have expressed in a previous post, that 'eval' is an undefined command: part of its functionality is about mathematics and part about data structures. It cannot do both things well. So, its needs to be splitted into two distinct commands.

series(q,a=1/3,2);

                       1     (2/3)   (1/3)    /    1\
                       -- 108      13      + O|a - -|
                       54                     \    3/
map(evalf,%);
                                           /    1\
                           0.9874986897 + O|a - -|
                                           \    3/

limit(q,a=1/3);
                                  undefined
MultiSeries:-limit(q,a=1/3);
                                  undefined

MultiSeries:-series(q,a=1/3,2);
map(radnormal,%);
map(evalf,%);


                                 2                   /    1\
                 - ------------------------------ + O|a - -|
                                            (1/3)    \    3/
                     /   2     (1/2)  (1/2)\                
                   3 |- --- 676      9     |                
                     \  507                /                
                       1     (2/3)   (1/3)    /    1\
                       - (-4)      13      + O|a - -|
                       6                      \    3/
                                                    /    1\
                  -0.4937493449 + 0.8551989515 I + O|a - -|
                                                    \    3/

This MultiSeries is the latest algolib version on Maple 12.

PS Interesting: This plot 

dq:=denom(q);
plot([Re(dq),Im(dq)],a=0..1/2);

may explain why different series expansions produce different results, and the limits give "undefined" if they use a L'Hospital rule or something equivalent, as the derivative of the denominator change at a=1/3.

PS2 These other plots seem to show that the real and imaginary parts of the denominator on the complex plane are piecewise linear, with the planes meeting in a kind of "origami" pattern at a=1/3:

plots:-complexplot3d([Re(dq),.4],a=0-0.2*I..0.5+0.2*I,axes=boxed); plots:-complexplot3d([Im(dq),.2],a=0-0.2*I..0.5+0.2*I,axes=boxed);

I see at the end of Talk:Maple (software) a report on a pattern of similar "edits" lately. Just browsed Wikipedia:Vandalism, and may be the case. Whatever its technical qualification, its seems to me a childish behavior.

I see also, reading this discussion page, that several other staff members of Maplesoft are active participants in Wikipedia, eg: Will (user Redune) and DJ Clayworth. The latter says in his page: "I do a lot of vandalism reversion and recent changes patrol". Probably he is in an excelent position to revert and avoid vandalism in this page.

p:=convert(%,polynom):
collect(p,[c0,c1,c2,c3],distributed);

gives the polynomials.

p:=convert(%,polynom):
collect(p,[c0,c1,c2,c3],distributed);

gives the polynomials.

Sure, as many abused notations, it is false. A person doing hand calculations, with  enough inteligence, can keep the context in mind and revert to the correct definition/notation when necessary for a particular calculation. But the current available CAS as Maple, provide little intelligence and context. So, such notations, which are convenient in hand calculations, become dangerous in computer calculations.

This is another case where the intention of presenting calculations as they look when done by hand, may have problems.

Yes, this is a usual abuse of notation among Physicists.

is more "active" in simplifying. This may be better "aesthetically" (though sometimes unwanted), but  the manual  guidance  to find the result is still needed, eg:

PDEtools:-dchange(eta=-theta,J);
IntegrationTools:-Expand(%);
normal(%);
value(%);

As an incidental observation, with "algolib" in the 'libname' path, I get an error message here:

IntegrationTools:-Change(J, eta = -theta);

Error, (in IntegrationTools:-Change) invalid input: simplify/infinity/exact uses a 1st argument, expr, which is missing

This problem persists sometimes, even after "algolib" is removed from the path by reasigning 'libname' within the session.

It needs some help:

pdsolve(PDE, f(x,t),HINT=`+`,build);


                              2
        f(x, t) = -1/2 _c[2] x  + _C1 x + _C2 + _c[2] t + _C3