@acer Thank you! That’s perfect. I came across only a few cases where repetition occurs, and this will save me the trouble of handling them separately.

Admitting my total lack of skill (even though I've been a Maple user for years) and hoping it's not too much trouble — how could the following procedure be modified to use the ordering established above?

monomialsGB := proc (p::algebraic, vars::list)
local
     M,
     v:= indets(p, suffixed({vars[]})),
     C:= coeffs(expand(p), v, 'M'),
     P:= plex(ListTools:-Reverse([v[]])[]),
     S:= sort(`[]`~([C],[M]), (a,b)-> not Groebner:-TestOrder(a[2], b[2], P));
     (map2(op, 1, S), map2(op, 2, S)):
end proc:

Please include details on how you modified the procedure. I really need to learn the basics of Maple once and for all.

@acer Many thanks.  Yes, there is the possibility of repeated terms.

@acer As usual, you went above and beyond—thank you for that! It's a great way for me to learn more about Maple commands. In the cases I typically work with, the entries usually have the same level of nesting.

@acer Thank you for making it clear.  The inner most entries are number (integers, rationals and possbily reals) and/or symbols (variables), or empty. In cases I am interested in they are a solution of an equation.   

@acer Sorry if I'm missing something obvious—could you clarify what exactly makes it under-specified?

@acer Many thanks.   After the first outer list, entries are either lists or sets.

@acer Thank you!  

@acer Could you explain why ":-coef" is used, please?   Thanks. 

@acer Yes, it is—thanks for pointing out the SubstituteAll function!  

@acer Wow! Thanks so much for the thorough explanation — it really helped me a lot.
I’m always forgetting some of the things you and Carl explained in your previous replies to my questions.
Thanks for your patience, both of you!

@Carl Love Many thanks! After your message, I started using assuming instead of assume, and as you said, it's definitely easier to work with.

@dharr Many many thanks. Perhaps you could help me to understand why adding the following assumptions makes it worse.

assume(beta,'real',beta>0);
assume(sigma,'real',sigma>0);
assume(rho,'real',rho>0);

@aroche Sure, here they are.  I have both Maple 2024 and 2025 and the results are the same.

eqqq := map(simplify,{sqrt(beta*rho*xi[8]^2 - beta*xi[8]^2)/xi[8] = sqrt(beta*rho - beta), (-rho + 1 + sqrt(beta*rho*xi[8]^2 - beta*xi[8]^2))/(xi[3]*xi[8] - 1) = sqrt(beta*rho - beta), -(-rho*xi[3]*xi[8] + sqrt(beta*rho*xi[8]^2 - beta*xi[8]^2) + xi[3]*xi[8])/(xi[8]*(xi[3]*xi[8] - 1)) = rho - 1});

sol:=solve(eqqq,{xi[8],xi[3]});

simplify(subs(sol,eqqq));

evalf(subs({sigma=10,beta=8/3,rho=28},%));

 @dharr I was surprised that solve and SolveTools:-PolynomialSystem returned a different number of solutions, so I ran a small experiment. I took all combinations of six unknowns and used both solve and SolveTools:-PolynomialSystem to compute the solutions: solve returned 2,170 solutions, while SolveTools:-PolynomialSystem returned only 21 (after doing my best to eliminate duplicates and common solutions). The difference is significant.

Update: I have to check the solutions further.

@dharr I can't use solve or SolveTools:-PolynomialSystem as you did.   They are always divided into two sets: one containing \alpha_{9,*,*} and the other containing \alpha_{14,*,*}. When a solution is found using one of these sets, it always depends on the other set or includes a free parameter. I found only one solution when using all the unknowns \alpha_{9,*,*}.

The answer to your question is yes, they are different solutions.