If you want to simplify an expression under the assumption that all of its variables are real, use evalc. For example,

evalc(temp1b)

will remove all the overbars, because conjugation is the identity function on real expressions.

That depends on whether you know, numerically, where the "top" is. If you know that the top is at 10, for example, you could do

plot([[5,0], [5,10]])

This is how the same thing can be achieved with the updating append operator ,=. The benefit of this operator is that you don't need to keep track of or increment the indices within the loop.

V:= Array(1..0): #empty
for k to 10 do
    V,= k/10.
od:
rtable_options(V, subtype= Vector[row]);
V;
[0.1000000000, 0.2000000000, 0.3000000000, 0.4000000000, 0.5000000000, 
 0.6000000000, 0.7000000000, 0.8000000000, 0.9000000000, 1.000000000]

For reasons that I don't understand, you must start with an Array rather than a Vector to do this. But the rtable_options command converts it to a Vector inplace, so that's a constant-time trivial operation (i.e., regardless of the number of elements). Anyway, it's very likely that an Array will work just as well as a Vector for your purpose.

Like all of the basic syntax features added in the last three major releases (Maple 2018 - 2020), the ,= operator is only usable in 1D input (aka Maple Input).

The following test plot shows that the lines are laid down in the order that they appear in the code:

plot([[[0,0],[1,1]],[[1,0],[0,1]]], thickness= 20);

However, when I tested the same thing a very long time ago (nearly 20 years), the lines were laid down in the reverse order that they appeared in the code. Since you're using a very old version of Maple, you should do this simple test.

Modifying my previous Answer (to which Acer linked) for non-constant theta(t) is easy. Here it is. I've highlighted in green the parts that you might want to vary. This code uses embedded assignments (highlighted in violet), which were introduced in Maple 2019 (maybe 2018). If you're using earlier Maple, I can easily modify this. Let me know.

plots:-display( #needed to get polar axes
    plottools:-transform((t,r)-> r*~[cos,sin](t))( #transform to polar
        DEtools:-phaseportrait(
            [
                diff(r(t),t) = r(t)^2*(r(t)+sin(theta(t))), 
                diff(theta(t),t) = r(t)^3*(r(t)+theta(t)+cos(theta(t)))
            ],
            [theta,r](t), 
            t= 0..0.5, #independent variable range for all trajectories 
            (i0:= map2(`~`[`=`], [theta,r](0), `[]`~(Pi/8*~[$0..15], .75))), #inits
            linecolor= [seq(COLOR(HSV, .85*i/ni, .85, .7), i= 0..(ni:= nops(i0)-1))],
            thickness= 1, #trajectory thickness (min. is 0, not 1)
            method= rkf45, stepsize= 0.0005,
            color= COLOR(HSV, 0, 0, .85), #light-grey arrows
            arrowsize= .3
        )
    ), 
    axiscoordinates= polar, size= [800$2], 
    axis[2]= [tickmarks= [subticks= 0]], axis[1]= [gridlines= false]
);

Notice that the trajectories that start at Pi/4 <= theta(0) <= Pi/2 are much longer than the others.

I don't fully understand your request, but surely a single remove command can do the job in its entirety without any need of the indices k of elements removed and without any need to consider the changing size of the list.

Why does conds return a list, not a set? Why does this code need lists at all?

Do you want to remove all triples from abc that contain any member of conds(...), i.e., for which there's nonempty intersection? Then do this:

parms:= {seq(seq(alpha[i,j], j= 0..9),i= 1..3)}: #set
abc:= combinat:-choose(parms,3):

T1:= table([2= 3, 3= 2, 5= 6, 6= 5, 7= 9, 9= 7]):
T2:= table([2= 3, 3= 2]):
T:= (T::table, j)-> `if`(assigned(T[j]), T[j], j):

conds:= (varCoef::set(specindex(alpha)))-> 
    map(x-> `?[]`(alpha, zip(T, [T2,T1], [op(x)])), varCoef)
:
cond:= conds(abc[1]):
remove(s-> s intersect cond <> {}, abc); 

The phenomenon is well explained by VV. I just want to point out that there's a fundamental contradiction in using Digits:= n for n > 15 with evalhf. Thus, it's no surprise that nonsense results. The command evalhf works at a fixed precision that's often call double precision in other languages. It follows very precise and standardized rules that are set down by IEEE and followed by nearly all processor manufacturers.

Not only is your code unnecessarily lengthy, it is also inefficient timewise and unadaptable to different graph orders.

To partition a list, set, etc., into equivalence classes, use ListTools:-Classify, like this:

GT:= GraphTheory: LT:= ListTools:
TG:= LT:-Classify(
    GT:-Diameter, 
    [GT:-NonIsomorphicGraphs](
        7, 
        output= graphs, 
        outputform= graph, 
        restrictto= connected
    )
):

At this point, TG[k] is the set of all graphs from the list of diameter k; in other words, it's the equivalence class. The equivalence classes can be counted by

TGn:= nops~(TG);
             TGn := table([1 = 1, 2 = 373, 3 = 387, 4 = 82, 5 = 9, 6 = 1])

The kind of fine type discrimination that you're describing can be done as follows: Let T1 and T2 be any individual types or sets of types. Then the type "all things that are T1 but not T2" is constructed as And(T1, Not(T2)). I can't imagine any situation such as you're describing that can't be handled by this mechanism.

The :: operator is very convenient for type checking. For example,

if x::And(algebraic, Not({name, constant, numeric}) then ....

The conditional expression above is equivalent to type(x, And(...)).

Here is your code with some small improvements that I'd recommend, including the correction to your original problem. Now, each intermediary variable is assigned before it is referenced. (That's usually a good way to go, although it's not mandatory in a "symbolic" language such as Maple.)

restart:
Digits:= 15: #becuase you have 15-digit constants in the code.
tmin:=10: #°C 	
tmax:=70: #°C 	
Tmin:= evalf[5](convert(tmin, temperature, Celsius, kelvin)):	
Tmax:= evalf[5](convert(tmax, temperature, Celsius, kelvin)):
alfa:= 0.3:		
i:= 0:
for T from Tmin by 2 to Tmax+1.25 do
    a12:= 2305.28444347652 - 9.14490843016421*T + 0.00680052257590234*T^2:
    a21:= -6665.24838284836 + 46.0897018087247*T - 0.0694991633494123*T^2:
    x2:= 1-x1:
    tau12:= a12/T:
    tau21:= a21/T:
    G12:= exp(-alfa*tau12): 
    G21:= exp(-alfa*tau21):
    lng1:= x2^2*(tau21*(G21/(x1+x2*G21))^2+tau12*(G12/((x2+x1*G12)^2))):
    lng2:= x1^2*(tau12*(G12/(x2+x1*G12))^2+tau21*(G21/((x1+x2*G21)^2))):
    lnga1:= subs(x1=xa1,lng1):
    lngb1:= subs(x1=xb1,lng1):
    lnga2:= subs(x1=xa1,lng2):
    lngb2:= subs(x1=xb1,lng2):
    r1:= lnga1+ln(xa1)=lngb1+ln(xb1):
    r2:= lnga2+ln(1-xa1)=lngb2+ln(1-xb1):
    r:= fsolve({r1,r2}, {xa1= 0..0.22, xb1= 0.22..1}):
    i:= i+1;
    #Guard against the possibility that fsolve doesn't finish:
    if r::set(name= numeric) then
        xA1[i]:= eval(xa1, r): xB1[i]:= eval(xb1, r)
    else
        xA1[i]:= 'unknown'; xB1[i]:= 'unknown'
    fi;
    print(i, T, xA1[i], xB1[i]);
od:

I present this Answer because I think that the while the Iterator package is definitely worthwhile using for this (it is very efficient both in time and memory), its syntax is quite unusual. Here is the code to generate all 6-combinations of a 9-set:

S:= {'rand'()$9}; #any set of size 9
#Generate all 6-combinations:
for C in Iterator:-Combination(nops(S), 6) do
     S[[seq(C+~1)]]
od;

Note the double square brackets. Note that C is a 1-D Array (with lower index 1) of 0-relative indices. Note that 1 is added to each element of C. Note that the iterator is passed no information about the base set, S, other than its size.

If you get an error related to the compiler, rerun with the option compile= false to the Combination command.

There are two main ways that Iterators can be run:

1. The index variable, which is always a 1-D Array with lower index 1, is the index variable in an "in-do" or "for-in-do" loop.
2. The index variable is the index variable of seq, add, or mul.

If I enter all the needed multiplication signs to your input (thus,

p:= -(729*beta*(1/2*(-1/9*(-5/27*beta-1/9)*lambda^6-1/9*(1/9*beta^2*TT+
(10/9*TE+2/3*TT)*beta-1/9*TE)*lambda^4+5/27*(2/5*TT*(3/2*TT+TE)*beta+TE*
(TE-2/5*TT))*beta*lambda^2-1/9*TE*beta^2*TT*(-TT+TE))*p1(m,t)^2+(beta*
TT-1/3*lambda^2)^2*(-1/3*lambda^2+TE)^3*((p2(m,t))/(lambda^2-3*TE)+3/2*(
(lambda^2+TE)*p1(m,t)^2)/((lambda^2-3*TE)^3))))/((3*beta*TT-lambda^2)^3*
(3*TE-lambda^2)^2);

) and then do 

normal(p);,

I get something equivalent to, and fairly close in form to, your desired output.

You can also get a nice form from

simplify(p);

If your goal is to prove that the two forms are equivalent, then enter the second form (thus,

s:= -3*beta*p2(m,t)/(lambda^2-3*beta*TT)+3*beta^2*(5*lambda^2-3*beta*TT)*
p1(m,t)^2/(2*(lambda^2-3*beta*TT)^3);

), and just do

simplify(p-s);
      0

Modulo the possibility of a bug (which seems extremely unlikely for simple rational functions such as these), simplification to 0 is a solid proof of equivalence (over the complex numbers).

Like this:

T:= table([2= 3, 3= 2, 5= 6, 6= 5, 7= 9, 9= 7]):
subsindets(
    varA, 
    `?[]`~(A, `[]`~(anything, {indices(T,'nolist')})), 
    a-> B[op(1,a), T[op(2,a)]]
);

As a single call:

map(op~, [1,2], ans1)

If you're using Maple 2019 or later, you can do this:

A:= Array([4]);
a:= A[-1]: to 3 do A,= ++a od;

The ,= is the new "append" operator, which is especially useful for efficiently appending to Arrays. 

The ++ is a new operator that does exactly what it does in C++: ++a adds 1 to a, stores the result in a, and returns the updated value.

The A[-1] gets the last element of A (which is also the first element in this case). This is not new syntax.

You can use seq like this:

A:= Array([4]):
n:= 3:
u:= upperbound(A): 
a:= A[-1]: A(u+1..u+n):= <seq(a+i, i= 1..n)>;

To me, that's nowhere near as clear as the new syntax.

All of the above assumes that you want to append to the end of the Array. If instead you want to insert new elements somewhere other than the end, that's still possible to do, but the commands required are quite different. Let me know if that's what you want.