@Carl Love You are right.  abs seems to consume all the available memory in some cases, bringing the server almost to a halt. Yes, the idea is to put e and -e in the same equivalence class (the symmetric roots included).   Unfortunately, there are some radicals involved in the calculations as well as polynomial and rational functions.  I thought I would not need to be worried about the solutions with radicals but some simple models proved me wrong.   Below is an example:

ans := {{y = sqrt(alpha[1, 7]*(X2 - alpha[1, 0]))/alpha[1, 7], z = -(2*X1*X2*alpha[2, 5] - 2*X1*alpha[1, 0]*alpha[2, 5] - X3)/(2*alpha[2, 3]*sqrt(alpha[1, 7]*(X2 - alpha[1, 0])))}, {y = -sqrt(alpha[1, 7]*(X2 - alpha[1, 0]))/alpha[1, 7], z = (2*X1*X2*alpha[2, 5] - 2*X1*alpha[1, 0]*alpha[2, 5] - X3)/(2*alpha[2, 3]*sqrt(alpha[1, 7]*(X2 - alpha[1, 0])))}}

@Carl Love Thanks.  Last question - I modified  RemoveSymmetrySols to accommodate another condition, that is, class[abs~(rhs~(e))][e] and it works as intended.  To compare it to the previous solution I need to add something to LIstTools:-Classify to do the same. Although I had it modified, I confess I am not sure if my solution is efficient as far as speed is concerned.   Can you help me again?   Many thanks.

op~(1, {entries}(ListTools:-Classify(w->abs~(rhs~(w)), Sol), 'nolist'));

@Carl Love Many thanks.  What I did not get was the use and the reason for ':-nolist' (especially the apostrophe and :~).

The use of table was very clever. I need to incorporate that into my procedures.  

@Carl Love Many thanks.  As soon as I get the results of a job that is running right now and I will have something to compare both procedures.  
 

Would you be so kind to explain what the line with op does? Specially the reason of the use of '. 
 

@Carl Love Sorry for using here as a reply to three earlier posts.  1)  Thanks for pointing out the use [],   2) I will definitely take into account what you said about the help pages and 3)  many thanks.   

Is ListTools:-Classify optimized for speed?   You know that I will have to use it for a large number of system of equations

@Carl Love Many thanks.  I am confused with what the help page says and that is the reason why I posted the question.  What does "partial solutions" mean?   If I add a notzero as {x,y} all solutions with a zero (x and y) are eliminated.  Does it mean that {x=0.y=0} is considered as partial solution?  

As for your solution I had to remove the last [] before it works.  

I know if I use set as you did if there are identical solutions (not in the case shown above) only one is kept. Can I do something similar with symmetric solutions?  That is, only one is kept.  

@vv Thank you for the answer. I am not sure if the answer will help test millions of equations but it surely helps me to understand some of the possibilities (without using assuming).  

@Carl Love Many thanks.  I will give a try on simplify(..., symbolic) and also check assuming real. 

Acer's answer helps me with another problem - part b) of my original post.  

@acer Thanks.  The methods are not top-secret at all: 1st Method - solve the general equation with unknown symbolic coefficients for the monomials (beta, for instance).  Then, by using the relation between beta coefficients and alpha coefficients (such as the ones you see in my first post), find the solution.  2nd Method -solve the system with original alpha coefficients (they have an intricate relationship that depends on other calculations).  
My expectation was to reduce the number of systems to be solved using the general equation.  Of course, I have no choice but to use Method 2 in some cases (again due to the relationships in the alpha coefficients). 

I hope this sheds some light on the problem.  

@acer Many thanks.   I will avoid evalb in future calculations.  Since I am away from my notebook, I wonder whether assuming is the key to all alternatives.  If so, that will make the comparison almost impossible since I have millions of such a system to be tested and I can't see how I will write a specific assuming for each one of them. 

@Carl Love Many thanks again.  I will test it over the weekend and let you know. Could you explain what rcurry does and why it is faster?

@Carl Love Many thanks.  I will use the wrapper from now on.   

@Carl Love Many thanks. I don't know how I could miss making M local (Sorry for wasting your time).   Once M was made local, Threads:-Map returned the same number of elements.  Some more tests are needed though.   

Normally order is important for me but not in this case. I guess I am used to putting the monomials in lists and don't think much about it.  

@Carl Love, First of all, thank you for the comment. I came across an example that seems to show what you mentioned in your comment.   If I use Grid-Seq instead, Maple returns the same result as in map. But when I try to use it with a much larger input (list or set),  the calculations with the nodes went rather okay (2 hours), but when collating the results the memory jumped from 50Gb to 200 GB, and it is still running (more than 12 hours).   

@ecterrab Many thanks.   I wasn't aware of hastype.  I should have checked "See also".  Sorry for wasting your time.