@tomleslie I'm not disagreeing with this Answer; using the stopperror command (from the debugger suite) like that is a perfectly decent suggestion here. (I vote up.)

But I will mention that the line of code on which the recursive assignment occurs might not always be the line of code that ought to be fixed.

In Tom's simple example it is clear that the problem lies all within a single line of code. But in a complicated program the line that does the assignment might be correct, with the coding mistake lying elsewhere. For example, it's not inherently wrong to have a pair of separate statements like, say,
   temp := sin(y);
and another, later statement,
   y := G(temp);
if earlier in the code y is assigned some value (a numeric value might be typical, etc). And that earlier code could be complicated, doing such earlier initialization according to a process or under a complicated decision tree. It's quite possible that a subtle mistake in that process could leave a logical hole -- a situation in which y is accidentally not initialized, with the recursive assignment error ensuing.

It's not always possible for a code analyzer to locate a specific line at which a recursive assignment might occur. And the line at which the recursive assignment occurs during execution is not necessarily the line of code which ought to be fixed.

Sorry if that seems at all obvious. I'm trying to clarify the OP's query, "Presumably there is an error in the Maple syntax that prevents execution... Why can't Maple 2023 tell me what line the error is on?".

@MaPal93 What is the end-goal to solving these systems symbolically? Is it something explained in one of your earlier, related Question threads?

ps. I don't see an explanation of "optimal", as I asked above.

@MaPal93 What do you mean by optimal when you write of the optimal 3-equations sub-system?

Going back a bit, there are sometimes alternate techniques which can more easily eastablish an absence of solutions, as opposed to requesting an attempt that would produce any/all such in full. That may be leverage to you.

In a somewhat related way, I don't know how useful some potentially enormous exact symbolic subsystem might actually be.

@MaPal93 There appear to be no solutions to your system EqN with all of lambda__1, lambda__2, & lambda__3 being real and positive.

Does this not mean something relevant to your attempt to solve the 3x3 EqN system?

newEqN:=eval(EqN,[lambda__1=v1,lambda__2=v2,lambda__3=v3]):

andmap(coulditbe,newEqN=~0) assuming v1>0,v2>0,v3>0;

             false

@MaPal93 There is also a Veil command in the LargeExpressions package.

That, along with `freeze`, can sometimes be useful. (But hiding dependencies upon variables might matter.)

@MaPal93 To me a tricky part of your Question is the bit about your wanting to find the optimal formulation (of some of t__1,t__2,t__3 in terms of some others, with other mixed terms).

I don't think that the temporary variables I showed is going to provide an avenue for that. At least, I don't see how it'd be any better than manipulations done using the tools algsubs, eliminate, simplify(...,{..}) aka "simplify-with-subrelations", or some basis generator.

But since you asked how it (ie. what I showed above) could be programmed, here is some fun. Some of the following is done a bit crudely. And there are more finesses possible.

Download rearrangingterms_q3a.mw

@Carl Love The type checks you've used,  suffixed(x) and suffixed(x, nonnegint) , could fail if the name x itself were assigned. Now that I come to think of it, I suppose that the name suffixed is (alas) not protected.

So those type specs could all get wrapped in uneval-quotes, to guard against those cases.

@sursumCorda I thought that my wording -- and what I computed, and how -- made it quite clear and obvious that it provided no guarantee that there were no other solutions. I did allude to the larger problem as being fundamentally different.

I showed it primarily because nobody (including you) had yet showed any way to programmatically generate the as-yet known five exact solutions.

@MaPal93 Please don't start another separate Question thread for this.

The degree call fails because of the presence in its numerator of abs(Psi(t)) and other abs calls containing Psi(t).

That is the significant problem with your question.

Also, the numerator of your expression contains the capitalized term Psi(t). Is that deliberate?

Also the denominator of your expression eq contains the term psi(t). Is that deliberate?

Once you sort out these usage mistakes and syntax muddles, note also that Psi has a predefined and special meaning in Maple. Eg, Psi(0.3) produces the value of approximately -3.503. If you want to use the name Psi as if it were not predefined then you could put the declaration,
   local Psi;
at the start of your worksheet (after any restart).

@sursumCorda There will always be plenty of scope for improvement in any significant piece of software.

@Carlos36r 

Download ineq_rel_Carlos_real.mw

I don't really understand why you're taking this approach altogether. It's a very roundabout way of calling solve, that could be done directly, otherwise. I only showed it originally as example of conversions either way -- not as an ideal way to utilize solve.

How do you feel about the solution 
   lambda=0, h=T, T<>0
?

What about the following (where h is real for lambda<0),
   T=0, h=-(6*14^(2/3))/(7*(-lambda)^(1/3))
?

Do you need purely real solutions? Do you have any restrictions on the variables?

Here's another example, with irregular spacing in the x-values. I'll take it as given that the x- and y-values are already suitable sorted.

It's a little tricky to get the forced tickmarks to be just right. For one thing, the GUI refuses to add an x-tick if it's too close to a default-generated y-tick. So some compromise is needed.

But here are some variants. I don't want to get bogged down in a really complicated procedure to figure out nice, evenly spaced, rational forced/faked x-tick values, etc.

plot_2_ac.mw