@Carl Love Thanks for the input. I had some other problems with my calculation that I had to address first. This worked great.  

@dharr OK. I know what you mean now.

Thanks for the help.

@dharr That looks like what I want. I'll play with this a bit.

Could you elaborate on "Likewise the group operation could instead be more generic, say '.' ?"
'.' is the non-commutative multiplication right?

Thanks for the insights.

@Carl Love I have everything implemented and it's working fine. Thanks.

@acer Thanks for the inputs.

First, yes I do want the 1 and -1 cases. Actually I want 0 too, but that's a bit trickier since xi^0=1, and it's gone by the time I get to the step I'm on. [If you have any idea how to force Maple to keep xi^0 terms, that would be useful. I'm multiplying these xi terms together. So any time I get something like 1/xi*xi, the xi term disappears instead of being xi^0]

Second, the infinite loop was occuring for the reason you mention. applyrule re-applies the rule [As I expected].
I tried to have the applyrule return a frozen value, but that doesn't seem to work (i.e., I'm not good enough with Maple). I realized I could use an intermediary dummy variable, but I thought that was a bit inelegant - and possibly slow.

Thanks again.

@acer Thanks. I was close but not close enough!

I will have to play around more with your freeze/thaw way of doing it. I had tried that to no avail.
I had more or less done what you did in example 2, but was trying to avoid the double substitution.

Thanks.

@Carl Love Thanks. I had tried identical but I guess the rest of my formulation (which was different) was wrong.

@Carl Love 

I forgot to show that it doesn't optimize anymore. I am trying to keep the example simple.

Thanks.

@Joe Riel Thanks.

Just curious why it takes a double expansion?

@Carl Love
The coefficients are real.
Assume doesn't really answer the conjugation question. It should still be able to distribute the operation across the sum.

Assume doesn't change the result.

Further thoughts?

@vv Thanks. I corrected the link.

@Mariusz Iwaniuk I'm not trying to get the result; it is quite obvious. My example was a simplified version to draw attention to the root of the problem, i.e. Maple doesn't recognize the derivative of x^n (for n=0) as identically equal to zero when it is inside a Sum. This leads to other bizarre and erroneous behaviors.
[moderator: see edited Question and attachment]

@Scot Gould That is technically a correct result but not what I was looking for. It hasn't recognized that the n=0 term is identically zero.

Why does it matter? My question was just a simplified version of a more complicated question. I was trying to get to the root of the matter. Many problems result from not creating a special case for differentiation of the constant polynomial (e.g. x^0).
​​​​​​​[moderator: see edited Question and attachment]

@nm I meant the case of n=0. I've edited the post to reflect this.

This may be how computer algebra systems have traditionally worked, but it seems like a weakness to me.

Maybe the solution is really in how sum/Sum works.

@vv Hi. I meant to say for n=0. I have edited the original post.

I guess my problem is more with how simplifications are not done on the sum/Sum procedure. I was thinking it would be easier to do the simplifications if the n=0 term was expressly called out.